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: | Chris Dodd <cdodd@acm.org> |
Newsgroups: | comp.compilers |
Date: | Sun, 11 Jan 2009 18:14:50 -0600 |
Organization: | Compilers Central |
References: | 09-01-012 |
Keywords: | code, optimize |
Posted-Date: | 12 Jan 2009 15:32:05 EST |
On 09 Jan 2009, you wrote in comp.compilers:
> I am currently writing a small compiler as a hobby project. My
> register allocator is basicly working but I have no idea how I could
> model the condition code register (rflags) properly. AMD64 is my
> current backend. My intermediate representation (SSA based) handles
> comparisons and conditional jumps like this at the moment:
One trick I've used for dealing with condition-code base ISAs (like x86) is
to treat each condition-code register as a set of 'mutually exclusive'
boolean registers each of which can hold the result of a particular
comparison. You generally call these CC_LT, CC_LE, CC_EQ, CC_GT. etc, and
have your register allocator understand that they all overlap (so writing a
boolean value to one clobbers the others), and that a '<' operation (for
example) can only write to CC_LT and not any of the other registers. The
cond-branch instruction can take its source (the condition) from any of these
registers, and then when you go to emit the instruction, which source
register is used determines which instruction to use.
So for your code:
> d = a > 10
> IF d GOTO label1
your register allocator might assign a to %rax and d to CC_GT, and the code
would become
cmp %rax, 10
bgt label1
This all fits in well with any kind of constraint-based register allocator
(graph coloring or otherwise), as long as you have the ability to specify
overlap constraints on registers. For something like x86, you already need
that to handle things like %eax overlapping with both %al and %ah. It also
extends nicely to handle multiple CC registers, such as on sparc.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.