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

[Jeff Law]

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