Re: Return slot optimization for stack protector strong

[Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>]

On Tue, Jan 28, 2020 at 06:18:41PM +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote:
> > On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> > > some function calls trigger the stack-protector-strong although such
> > > calls are later on implemented via calls to internal functions.
> > > Consider the following example:
> > > 
> > >     long double
> > >     rintl_wrapper (long double x)
> > >     {
> > >       return rintl (x);
> > >     }
> > > 
> > > On s390x a return value of type `long double` is passed via a return
> > > slot.  Thus according to function `stack_protect_return_slot_p` a
> > > function call like `rintl (x)` triggers the stack-protector-strong since
> > > rintl is not an internal function.  However, in a later stage, during
> > > `expand_call_stmt`, such a call is implemented via a call to an internal
> > > function.  This means in the example, the call `rintl (x)` is expanded
> > > into an assembler instruction with register operands only.  Thus this
> > > late time decision renders the usage of the stack protector superfluous.
> > 
> > I doubt your predicate gives any guarantees that the builtin will be
> > expanded inline rather than a library call.  Some builtins might be expanded
> > inline or as a library call depending on various options, or depending on
> > particular arguments etc.
> 
> My predicate is more or less just a copy of what happens in
> `expand_call_stmt` where we have
> 
>     decl = gimple_call_fndecl (stmt);
>     if (gimple_call_lhs (stmt)
>         && !gimple_has_side_effects (stmt)
>         && (optimize || (decl && called_as_built_in (decl))))
>       {
>         internal_fn ifn = replacement_internal_fn (stmt);
>         if (ifn != IFN_LAST)
>           {
>             expand_internal_call (ifn, stmt);
>             return;
>           }
>       }
> 
> There a decision is made whether a call is implemented as a call to an
> internal function or not.  Thus using the very same logic it should be
> possible to decide at an earlier stage that a call will be implemented
> as a call to an internal function.  Since an internal function has no
> linkage, it is therefore guaranteed that it will be inlined.

Ping. Any chance we can have a second look at this? I just outsourced the
logic used in `expand_call_stmt` in order to determine whether a call is
realized as a call to an internal function or not, into a predicate.
This predicate I'm then using to decide whether a function call should
trigger the stack protector or not.

I would have thought that this is fine since internal functions are
guaranteed to be inlined. Am I missing something?