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

[Devang Patel]

On Sep 26, 2008, at 2:37 AM, Duncan Sands wrote:

>> - what if NS calls S ?
>>
>> 	Simple. After inlining, NS will run on a processor that has no sse
>> support. So, inline S into NS only if code generator will not be
>> forced to use SSE instructions for the code copied from S.
>
> So the inliner needs to know all about how codegen works?
> I don't think Chris is going to like that!  This doesn't
> seem simple to me.

The inliner needs to know the LLVM IR for function S does not use SSE  
intrinsics in this case. The inliner needs to detect SSE uses at IR  
level.

Regarding code gen, it is code generator's responsibility to not use  
SSE when function is marked as x86.no-sse. This is a contract which  
code generator has to respect irrespective of inliner.

We have supported similar scenario (with lots of pain because of lack  
of surrounding infrastructure) earlier. Ask me offline if you're  
interested.

>> If XYZ calls S and NS then once again, XYZ's notes win.
>
> And could result in a huge performance loss.  And it is a loss:
> it was ok to run S using sse instructions (that's why the
> function was marked "sse"!), but now sse isn't being used due
> to inlining...

... this happens only if because XYZ is marked as x86.no-sse. In which  
case, it is not a performance loss at all.

> 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" :)

-
Devang