This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA/RFC] Stack clash mitigation patch 05/08
- From: Jeff Law <law at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 20 Jul 2017 08:20:52 -0600
- Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 05/08
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9351A72D09
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9351A72D09
- References: <91c49a05-cb65-a850-a653-d181749075dc@redhat.com> <20170720130927.GZ13471@gate.crashing.org>
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