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

[Duncan Sands]

> > 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.

This is indeed what I understand your strategy to be.

> 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.

Got some examples?  Remember that I'm not talking about the case:
  gcc -c -O4 x.c      <= function B in here
  gcc -c -O4 -sse y.c <= function A in here
  gcc -o x x.o y.o    <= do LTO
In the scheme I'm suggesting in this case A would be marked "sse"
while B would be marked "don't care" for sse (i.e. no marking).
Which means that in both your scheme and mine the inliner can
inline B into A, with the final function being sse codegened.

I'm talking about this case:
  gcc -c -O4 -no-sse x.c <= sse explicitly turned off
  gcc -c -O4 -sse y.c
  gcc -o x x.o y.o
Here you would still happily inline B into A, while my
scheme would not.  Do you really have examples of this
being a problem in practice - cases when someone explicitly
said -no-sse but it was somehow a problem that sse wasn't
used after all?

> IMO, after inlining the callee function loses its identify inside  
> caller and becomes part of caller. 

If you *choose* to inline B into A then B losses it's personality.
That's not the issue - the issue is when to make this choice.

Ciao,

Duncan.