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
