This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386]: Fix PR target/35553, -fkeep-inline-functions and -O errors our in SSE headers


On Thu, Mar 13, 2008 at 10:01:29AM -0400, Jonathan Lennox wrote:
> On Thursday, March 13 2008, "Jakub Jelinek" wrote to "Jonathan Lennox, Uros Bizjak, Richard Guenther, gcc patches" saying:
> 
> > -fno-inline is a non-issue, as always_inline attribute is stronger than
> > -fno-inline.
> 
> Why is #ifdef __OPTIMIZE__ needed in these files, then?  If always_inline
> functions are inlined even at -O0, it seems like the inline functions ought
> to work even for the functions which need immediate arguments.

Please reread what I've said earlier today, or try the testcase I posted:
extern void baz (int);
extern __inline __attribute__((__gnu_inline__, __always_inline__, __artificial__))
void foo (int i)
{
  baz (i);
}
void bar (void)
{
  foo (6);
}

Compile that with -O0 -fdump-tree-apply_inline and also with -O1 -fdump-tree-optimized.
You'll see that in apply_inline dump which is the last before expansion you
have
  i = 6;
  baz (i);
and therefore the builtin expansion won't see that the argument is
INTEGER_CST.  In the optimized dump there is baz (6);, so the expander sees
it.

> > And I don't think we care or should support taking addresses of _mm_*
> > functions, nobody says they are functions, that's an implementation detail.
> > In fact some of them are even sometimes defined as macros, and you can't
> > take address of a macro.
> 
> Paolo's suggestion of forbidding taking the address of __artificial__
> functions seems like a good one.

Nope.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]