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

[Chris Lattner]

On Nov 21, 2008, at 4:05 PM, Bill Wendling wrote:

> On Nov 21, 2008, at 3:50 PM, Chris Lattner 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
>>
>> This doesn't work.  LLVM IR needs to be context sensitive.  For
>> example, what are the flags produce by an identity bitcast or phi
>> node?  The code above should be semantically equivalent if you insert
>> identity bitcasts.  This is exactly the problem that some of the
>> vector lane proposals hit.
>>
>> These would have to be equivalent for this to be feasible:
>>
>>> 	%sum = add i32 %v1, %v2
>>> 	%of = flag of i32 %sum
>>> 	br i1 %of, label %overflow, label %normal
>>
>>
>>
>>> %sum = add i32 %v1, %v2
>>  %tmp = bitcast i32 %sum to i32
>>> %of = flag of i32 %tmp
>>> br i1 %of, label %overflow, label %normal
>>
>> Similarly for phis, call arguments, etc.
>>
> The flag instruction could transitively look through identity casts
> and phi nodes for the instruction?

No.

There is no difference between a phi node and a call argument.  I  
should be able to extract the add out into a call of another  
function.  Do you propose codegen do interprocedural analysis to find  
this out?  What if the call becomes an external function?

There are many good reasons not to do this.

-Chris