[PATCH, i386]: Fix PR target/35553, -fkeep-inline-functions and -O errors our in SSE headers
Richard Guenther
richard.guenther@gmail.com
Thu Mar 13 14:24:00 GMT 2008
On Thu, Mar 13, 2008 at 3:12 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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.
That could be fixed if we were going into-SSA for -O0 via the constant
propagation done at inlining time. Then you'd get the same behavior
as for the macro.
Richard.
More information about the Gcc-patches
mailing list