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

[Evan Cheng]

On Nov 21, 2008, at 2:10 PM, Bill Wendling wrote:

> 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.

I am not sure why we would need this. At llvm level, icmp etc. will  
just produce a bool. In codegen we already have a way to model  
condition code as a physical register. burr scheduler already  
understands it and will avoid scheduling any instruction between  
something that produces a flag and its use.

Evan

>
>
> Comments?
>
> -bw
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits