Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Jakub Jelinek wrote:
> On Wed, Jul 12, 2017 at 12:20:32AM +0000, Wilco Dijkstra wrote:

> > Therefore even when using a tiny 4K probe size we can safely adjust SP by 3KB
> > before needing an explicit probe - now only 0.6% of functions need a probe.
> > If we choose a proper minimum probe distance, say 64KB, explicit probes are
> > basically non-existent (just 35 functions, or ~0.02% of all functions are > 64KB).
> > Clearly inserting probes can be the default as the impact on code quality is negligible.
> 
> For non-leaf functions you need at least one probe no matter how small the
> frame size is (if it is bigger than 0), explicit or implicit, unless you
> perform IPA analysis on the callgraph and determine when that isn't needed,
> because you can have deep call stacks that would through functions that
> don't touch anything skip stack pages.  Of course, such probes can be stores
> of call used registers, it can be any store to the stack.

Well you need to save the return address somewhere, so a non-leaf function already
has an implicit probe before a call (even if shrinkwrapped). So it is not possible for a 
long sequence of function calls or a recursive function to jump the stack guard - the
only way to jump the guard is using a huge unchecked static or dynamic allocation.

One key thing to understand is that it doesn't matter where exactly the return address
is saved in a frame. You could save it at a random location and all it would mean is that
if the probe size is N, you only need to insert additional explicit probes if the frame is
larger than N/2 (sum of static and dynamic allocation). Obviously you could do better
than that with a well defined frame layout.

Before we consider IPA, how about optimizing trivial alloca's first? For example why
does GCC emit dynamic allocations for:

void f(void*);
void alloca (int x)
{
  if (x < 100)
    f (__builtin_alloca (x));
  f (__builtin_alloca (16));
}

Wilco