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

[Duncan Sands]

> > so any use of floating point (eg: fp multiplication) should be  
> > understood
> > as using SSE, and would stop the inliner from inlining?
> 
> Ignore inliner for a while, and decide what code generator should do  
> for following ?
> 
> define float @foo(float %a, float %b) x86_no_sse {
>         %t = mul float %a, %b
>         ret float %t
> }

PS: In this topic I've been talking about performance.  Perhaps
that wasn't clear.  Some relevant snippets from before:

> > ... this happens only if because XYZ is marked as x86.no-sse. In which  
> > case, it is not a performance loss at all.
>
> I don't understand what you are saying here.  Suppose XYZ is no-sse.
> It calls S which is marked sse and does a lot of floating point
> computation (but doesn't use sse intrinsics).  If I understand you
> right, the inliner can inline S into XYZ.  This results in all these
> floating point computations being done as "no-sse", i.e. using the
> good 'ol x86 floating point stack rather than the much more efficient
> sse registers...

...

> I think it's important to distinguish between cases where the note is
> required for correct behaviour, and where it simply indicates a preference.
>
> If it denotes a preference then it doesn't matter much if the inliner
> discards the note when inlining the function.  This is probably the
> case for most codegen options - they are about performance/code size,
> rather than about correctness.
>
> That said, suppose I compile A without any particular sse flags (eg:
> because it itself doesn't use any sse instructions).  Suppose B is
> compiled with sse because it does vector operations.  If LTO results
> in B being inlined into A, and that means that the vector operations
> are codegened without sse support - well, someone will be upset.