On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote:> On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > > > In looking at the LLVM reference manual, it is conspicuous that (a) > > the > > IR does not define condition codes, and (b) the IR does not define > > opcodes that return condition results in addition to their > > computational > > results. > > We currently don't have this because noone has implemented it yet. It > would be great to have this.I want to background process this for a bit, but it would be helpful to discuss some approaches first. There would appear to be three approaches: 1. Introduce a CC register class into the IR. This seems to be a fairly major overhaul. 2. Introduce a set of scalar and fp computation quasi-instructions that accept the same arguments as their computational counterparts, but produce *only* the condition code. For example: add i32 ... produces result add_cc i32 ... produces condition codes Once this exists, re-combine the instructions in the back end with peepholes. 3. Handle CC as a black magic special case, which at least has the merit of tradition. :-) Given the number of different ways that different bits of hardware handle CCs, I am inclined to think that the right approach, in abstract, is to introduce a CC register class and deal with CCs in a fully general way. If so, this is not a small change. Opinions/reactions?
Hi,> There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example: > > add i32 ... produces result > add_cc i32 ... produces condition codes > > Once this exists, re-combine the instructions in the back end with > peepholes. > > 3. Handle CC as a black magic special case, which at least has the > merit of tradition. :-)4. Do arithmetic in a type with one more bit. For example, suppose you want to know if an i32 add "x+y" will overflow. Extend x and y to 33 bit integers, and do an i33 add. Inspect the upper bit to see if it overflowed. Truncate to 32 bits to get the result. Probably codegen can be taught to implement this as a 32 bit add + inspection of the CC. Ciao, Duncan. PS: In order for codegen to be able to handle i33, you need to turn on the new LegalizeTypes infrastructure.
On Wed, 2008-03-26 at 15:07 +0100, Duncan Sands wrote:> 4. Do arithmetic in a type with one more bit. For example, suppose you > want to know if an i32 add "x+y" will overflow. Extend x and y to 33 > bit integers, and do an i33 add. Inspect the upper bit to see if it > overflowed. Truncate to 32 bits to get the result. Probably codegen > can be taught to implement this as a 32 bit add + inspection of the CC.As a quick fix, that isn't a bad solution for bignum arithmetic, but it doesn't deal with the upper bits from multiply, and it doesn't deal with floating point condition codes at all. shap
On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote:> I want to background process this for a bit, but it would be helpful to > discuss some approaches first. > > There would appear to be three approaches: > > 1. Introduce a CC register class into the IR. This seems to be a > fairly major overhaul. > > 2. Introduce a set of scalar and fp computation quasi-instructions > that accept the same arguments as their computational counterparts, > but produce *only* the condition code. For example:Why not define an "add with overflow" intrinsic that returns its value and overflow bit as an i1? -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wed, 2008-03-26 at 11:02 -0700, Chris Lattner wrote:> On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > I want to background process this for a bit, but it would be helpful to > > discuss some approaches first. > > > > There would appear to be three approaches: > > > > 1. Introduce a CC register class into the IR. This seems to be a > > fairly major overhaul. > > > > 2. Introduce a set of scalar and fp computation quasi-instructions > > that accept the same arguments as their computational counterparts, > > but produce *only* the condition code. For example: > > Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1?Chris: I understand several simple ways to implement add with carry. Your suggestion is one of them. What I'm trying to understand is how to handle the conditional code issue generally. shap
Hi Chris,> Why not define an "add with overflow" intrinsic that returns its value and > overflow bit as an i1?what's the point? We have this today with apint codegen (if you turn on LegalizeTypes). For example, this function define i1 @cc(i32 %x, i32 %y) { %xx = zext i32 %x to i33 %yy = zext i32 %y to i33 %s = add i33 %xx, %yy %tmp = lshr i33 %s, 32 %b = trunc i33 %tmp to i1 ret i1 %b } codegens (on x86-32) to cc: xorl %eax, %eax movl 4(%esp), %ecx addl 8(%esp), %ecx adcl $0, %eax andl $1, %eax ret which uses the condition code as desired. Pity about the redundant andl $1, %eax! Ciao, Duncan.