[llvm-commits] [llvm] r59756 - /llvm/trunk/include/llvm/Intrinsics.td
isanbard at gmail.com
Fri Nov 21 16:10:22 PST 2008
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
>> 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
>> 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
>> - 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
>> changing to the IR.
>> - It's easy for code gen to know what's happening here so it can try
>> to produce good code.
>> - Code motion can mess up the flags. For instance, another arithmetic
>> expression could be shoved in between the "add" and "flag"
>> 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
>> - 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.
More information about the llvm-commits