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

[Bill Wendling]

On Nov 21, 2008, at 3:47 PM, Evan Cheng wrote:

> On Nov 21, 2008, at 2:10 PM, Bill Wendling wrote:
>
>> 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.
>
My idea was to give the programmer an easy way to gain access to  
flags. It's not so much a problem of whether we can perform the checks  
in LLVM right now -- we can do this by doing the calculation in a  
larger bit size, then checking the appropriate bit to see if it  
overflowed/carried. It's easier for code gen to understand what's  
going on (that an overflow/carry/whatever flag is being checked), and  
generate good code for that situation.

-bw