[llvm-commits] r55638 - /llvm/trunk/include/llvm/Function.h

Devang Patel dpatel at apple.com
Fri Sep 26 13:32:55 PDT 2008


On Sep 26, 2008, at 1:11 PM, Duncan Sands wrote:

>>> How about this instead: have sse be a tri-state
>>> "sse", "no-sse" or don't care.  Have the inliner
>>> refuse to inline function B into function A if
>>> they have conflicting notes ("sse" conflicts with
>>> "no-sse", but "don't care" doesn't conflict with
>>> anything).
>>
>> I do not understand, why the inliner can not inline a function marked
>> as "x86.no-sse" into a function marked as "x86.sse"?  After all it is
>> not "x86.sse.only" :)
>
> Remember that it's a tri-state: no-sse doesn't mean "didn't specify
> sse", it means "explicitly said no sse".  If the user went to the
> trouble of explicitly saying "do not use sse for this function" it
> seems unwise to ignore that.

Let me summarize again.

Fn A calls Fn B.
After inlining a copy fn B code replaces call instructions inside A.
All the instructions (LLVM IR) copied from B is now owned by A. A is  
their new parent.

Now, If
Fn A is marked as x86.sse
Fn B is marked as x86.no-sse

Then after inlining the code copied from B becomes part of A. It does  
not matter whether Fn B is marked as x86.no-sse or not.

If during inlining attributes for caller and callee does not match  
then appropriate policy decisions have to be made. Skip if attributes  
do not match is very restrictive and does not make any sense. I have  
seen in practice, not just in theory, such situations.

> Maybe the example of a frame-pointer is clearer.  I think it's
> fairly common that people want to explicitly compile some functions
> with a frame pointer in order to help with debugging.  It seems
> reasonable to me that the inliner should refuse to inline a function
> with an explicitly requested "give this guy a frame pointer" into
> a function with an explicitly requested "don't give this guy a
> frame pointer".

IMO, after inlining the callee function loses its identify inside  
caller and becomes part of caller. Either way, We do not have to same  
logic to x86.no-sse vs x86.sse or other set of attributes.

> And don't forget the big advantage of this scheme:

... and don't forget big disadvantages of your approach!

-
Devang






More information about the llvm-commits mailing list