On 07/21/2017 02:25 PM, Segher Boessenkool wrote: > 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. FWIW, we found a case where the scheduler would muck things up. Essentially it has code rewrites address computations and memory references in the hopes of breaking dependency chains. In many ways it's a lot like c-s-a.
Anyway, it broke the dependency chain and as a result we ended up with unsafe sequences on aarch64. THe V3 patch posted last night addresses that in two ways. First the scheduler knows about the magic note in the same manner as c-s-a. And we emit scheduling barriers in the probing code to prevent undesirable movement. Jeff
