Related articles |
---|
Modeling the condition code register in register allocation roland.leissa@googlemail.com (=?ISO-8859-1?Q?Roland_Lei=DFa?=) (2009-01-09) |
Re: Modeling the condition code register in register allocation nightmie@gmail.com (nightmie) (2009-01-11) |
Re: Modeling the condition code register in register allocation cdodd@acm.org (Chris Dodd) (2009-01-11) |
Re: Modeling the condition code register in register allocation bartc@freeuk.com (Bartc) (2009-01-13) |
Re: Modeling the condition code register in register allocation roland.leissa@googlemail.com (=?ISO-8859-1?Q?Roland_Lei=DFa?=) (2009-01-13) |
From: | nightmie <nightmie@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 11 Jan 2009 01:35:57 -0800 (PST) |
Organization: | Compilers Central |
References: | 09-01-012 |
Keywords: | code, optimize |
Posted-Date: | 12 Jan 2009 15:31:08 EST |
On 10 ,q,_,S, 07:38, Roland Lei),a <roland.lei...@googlemail.com> wrote:
> The first variant touches rflags, the second doesn't. As one can
> easily see this will be tricky to model especially when the
> intermediate representation should be as architecture independent as
> possible.
>
> Some ideas or related papers?
Ideas:
1) Create IF_GREATER, IF_EQUAL etc commands in IR - this is the most
architecture independent variant.
2) Use peephole optimisation on generated code/IR
CMPQ $10, %rax
SETG %dl ;< Peephole optimizer sees these
TEST %dl, %dl ;< lines
JNZ label1 ;<
JMP label2
;
; and replace triplet SETG/TEST/JNZ (or whatever you use) with JG
;
CMPQ $10, %rax
JG label1
JMP label2
but beware that everything will die if %dl=(d>10) is used somewhere
in label1, label2. So such optimisation only can be used if optimzer
already proved that d variable not used in codeblocks reachable from
label1 and label2
Return to the
comp.compilers page.
Search the
comp.compilers archives again.