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

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Jul 20, 2017 at 08:20:52AM -0600, Jeff Law wrote:
> > Can only combine-stack-adjustments do this?  It seems like something
> > many passes could do, and then your new note doesn't help.
> SO far it's only been observed with c-s-a, but further auditing is
> certainly desirable here, particularly with the upcoming changes to the
> generic dynamic alloca handling.
> 
> In the V2 patch only backends would emit unrolled inline alloca/probe
> sequences like what you see above and only for prologues.  Thus there
> were a very limited number of passes to be concerned about.
> 
> In the V3 patch we have unrolled inline probing for the dynamic space as
> well, so this kind of sequence is exposed to everything after
> gimple->rtl expansion.
> 
> Unfortunately, the most thorough checker we have is x86 and on that
> target, because of stack alignment issues, we'll never see a constant
> size in the dynamic space and thus no unrolled inlined alloca/probe
> sequences.
> 
> In reality I suspect that with teh hard register references, most passes
> are going to leave those insns alone, but some auditing is necessary.

This is similar to what rs6000 uses stack_tie for.  You want the
prevent a store to the stack (the probe) from being moved after a
later stack pointer update.  By pretending (in the insn pattern)
there is a store to stack with that stack pointer update, nothing
can move stores after it.


Segher