[PATCH] Don't optimize builtins declared always_inline until after inlining (PR middle-end/38454)

Jakub Jelinek jakub@redhat.com
Tue Dec 9 17:32:00 GMT 2008

On Tue, Dec 09, 2008 at 06:12:46PM +0100, Richard Guenther wrote:
> On Tue, Dec 9, 2008 at 6:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > If we optimize away builtins that were defined in the headers as inlines
> > with always_inline attributes too early (before inlining), they aren't
> > ever inlined and thus whatever the headers wanted to do doesn't happen.
> >
> > On the memcpy-2.c testcase below it causes a regression since the more
> > aggressive memcpy folding was added - with -D_FORTIFY_SOURCE{,=2} it
> > might overflow a buffer with no compile time warning nor (worse) runtime
> > abort.  On memset-1.c it just makes the glibc warning about likely swapped
> > memset arguments ineffective.
> >
> > The following patch avoids folding builtins declared inline with
> > always_inline attribute until after inlining.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> !cfun->after_inlining is too agressive (it waits until the final ipa
> inliner pass).

We don't have a flag for "after early inlining".  Also, do we have any guarantee
that these always_inline functions are inlined already in early inlining?

> It is enough to have always_inline functions inlined which already happens
> during early inlining(?).  Also I think the extra checks need a comment _why_
> we actually want to delay folding.  There must be also a cheaper way of

I can add a comment, sure.

> testing for always_inline - DECL_DISREGARD_INLINE_LIMITS should be set on these
> functions.

DECL_DISREGARD_INLINE_LIMITS is weaker than that (set for any gnu_inline
extern inline).  I guess I could check DECL_DISREGARD_INLINE_LIMITS before
doing the more costly lookup_attribute.

> Also with delaying this folding - when does it then happen?  Only with the
> fold-all-builtins pass or earlier?

Usually fab, yes, worst case during expansion (most of expand_builtin_*
call fold_builtin_* first).


More information about the Gcc-patches mailing list