Re: [PATCH][PR target/84064] Fix assertion with -fstack-clash-protection

[Jeff Law <law at redhat dot com>]

On 01/30/2018 12:23 AM, Uros Bizjak wrote:
> On Tue, Jan 30, 2018 at 5:48 AM, Jeff Law <law@redhat.com> wrote:
>>
>>
>>
>> stack-clash-protection will sometimes force a prologue to use pushes to
>> save registers.  We try to limit how often that happens as it constrains
>> options for generating efficient prologue sequences for common cases.
>>
>> We check the value of TO_ALLOCATE in ix86_compute_frame_layout and if
>> it's greater than the probing interval, then we force the prologue to
>> use pushes to save integer registers.  That is conservatively correct
>> and allows freedom in the most common cases.  This is good.
>>
>> In expand_prologue we assert that the integer registers were saved via a
>> push anytime we *might* generate a probe, even if the size of the
>> allocated frame is too small to require explicit probing.  Naturally,
>> this conflicts with the code in ix86_compute_frame_layout that tries to
>> avoid forcing pushes instead of moves.
>>
>> This patch moves the assertion inside expand_prologue down to the points
>> where it actually needs to be true.  Specifically when we're generating
>> probes in a loop for -fstack-check or -fstack-clash-protection.
>>
>> [ Probing via calls to chkstk_ms is not affected by this change. ]
>>
>> Sorry to have to change this stuff for the 3rd time!
> 
> Now you see how many paths stack frame formation code has ;)
Never any doubt about that...  When it became clear that we were going
to need to mitigate stack-clash with new prologue sequences I nearly
cried knowing how painful this would be, particularly across multiple
architectures.

The good news is that with it being turned on by default in F28 we're
finding some of the dusty corners...

Jeff