[llvm-commits] [llvm] r59756 - /llvm/trunk/include/llvm/Intrinsics.td

[Bill Wendling]

On Nov 21, 2008, at 8:54 AM, Chris Lattner wrote:

> On Nov 21, 2008, at 5:56 AM, Duncan Sands wrote:
>
>>> Even if it does,
>>> transforming it the ADDC / ADDO + check probably requires quite a  
>>> bit
>>> of work in dag combine. We'd also like to support it in fast-isel. I
>>> think the intrinsics are needed, at least in the short term.
>>
>> Indeed, for the above i33 code you don't get a simple use of the  
>> carry
>> flag on x86.  I'm sure you used to, so I guess something changed.  In
>> any case the fact that you don't get a carry anymore at least proves
>> the
>> fragility of expecting codegen to reliably use a carry!   As you
>> say, to
>> make sure this happens consistently requires some work.  That said,
>> boosting
>> the power of integer codegen is a win for everyone, while using an
>> intrinsic
>> for overflow only helps those who use it.
>
> I completely agree that improving general integer codegen is useful.
> However, LLVM has long needed the ability to reason about integer
> overflow in general, and I don't think that i33 will solve all the
> problems :).  How do you do a signed add/sub, unsigned/signed mul,  
> etc?
>
I had an idea over lunch which may or may not be good. Here it is  
though.

What if we add a new LLVM instruction, called, say, "flag". It would  
be similar to the icmp instruction, but unary instead of binary. It  
would take a mnemonic operator for a flag and an arithmetic expression  
as its arguments. Here's an example:

	%sum = add i32 %v1, %v2
	%of = flag of i32 %sum
	br i1 %of, label %overflow, label %normal

Here, the "flag" command is checking to see if the addition  
overflowed. We can also have underflow, carry, zero, etc. flags  
returned. The code generator can then lower these calls like it does  
now.

Benefits:

- It explicitly models checking for overflow, underflow, etc.
   without needing to use large integer bit widths or doing messy
   arithmetic that complicates the DAG combiner.

- It's extensible. I.e., new flags can be tested easily without  
drastically
   changing to the IR.

- It's easy for code gen to know what's happening here so it can try
   to produce good code.

Drawbacks:

- Code motion can mess up the flags. For instance, another arithmetic
   expression could be shoved in between the "add" and "flag"  
instructions
   here, thus making a save of the flag necessary (because the hardware
   flag would be changed by the moved arithmetic expression). However,
   I think that all of the other proposed ideas suffer from this same
   problem.

- All of the passes will have to learn about this new instruction.

Comments?

-bw