This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA][PR target/84128] Fix restore of scratch register used in probing loops
- From: Jeff Law <law at redhat dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Uros Bizjak <ubizjak at gmail dot com>
- Date: Wed, 31 Jan 2018 08:48:17 -0700
- Subject: Re: [PATCH][RFA][PR target/84128] Fix restore of scratch register used in probing loops
- Authentication-results: sourceware.org; auth=none
- References: <328b4297-f032-6bf0-9252-1d7ee7b50133@redhat.com> <2119272.0doWMGaArI@polaris>
On 01/31/2018 01:28 AM, Eric Botcazou wrote:
>> -fstack-check and -fstack-clash both potentially create a loop for stack
>> probing. In that case they both need a scratch register to hold the
>> loop upper bound.
>>
>> The code to allocate a scratch register first starts with the
>> caller-saved registers as they're zero cost. Then it'll use any callee
>> saved register that is actually saved. If neither is available (say
>> because all the caller-saved regs are used for parameter passing and
>> there are no callee saved register used), then the allocation routine
>> will push %eax on the stack and the deallocation routine will pop it off
>> to restore its value.
>>
>> Of course there is a *stack allocation* between those two points. So
>> the pop ends up restoring garbage into the register.
>
> There is a stack allocation only on Linux, there isn't any on Solaris, *BSD,
> Windows, LynxOS and other OSes where you can probe below the stack pointer.
Ack. Let's hold the patch until I can test *that* path.
jeff