On 07/20/2017 07:09 AM, Segher Boessenkool wrote: > Hi Jeff, > > On Tue, Jul 18, 2017 at 11:17:48PM -0600, Jeff Law wrote: >> It turns out combine-stack-adjustments would take >> >> allocate PROBE_INTERVAL >> probe >> allocate PROBE_INTERVAL >> probe >> allocate PROBE_INTERVAL >> probe >> allocate RESIDUAL >> >> And turn that into >> >> allocate (3 * PROBE_INTERVAL) + residual >> probe >> probe >> probe >> >> Adjusting the address of the probes appropriately. Ugh. >> >> This patch introduces a new note that the backend can attach to a stack >> adjustment which essentially tells c-s-a to not merge it into other >> adjustments. THere's an x86 specific test to verify behavior. > > 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. Jeff
