This is the mail archive of the
mailing list for the GCC project.
Re: Spurious register spill with volatile function argument
- From: Andrew Haley <aph at redhat dot com>
- To: Michael Clark <michaeljclark at mac dot com>, gcc at gcc dot gnu dot org, cfe-dev at lists dot llvm dot org, Andrew Waterman <andrew at sifive dot com>
- Cc: RISC-V Software Developers <sw-dev at groups dot riscv dot org>
- Date: Mon, 28 Mar 2016 10:16:29 +0100
- Subject: Re: Spurious register spill with volatile function argument
- Authentication-results: sourceware.org; auth=none
- References: <2600D96D-94BC-4259-9D39-DE4993859281 at mac dot com> <9F3C9DE6-F00B-4402-A83B-354455DEAFFA at mac dot com> <CA++6G0CK3Yu-w9fhOrvpRP49qz9=Vs20J_=R28Mq=zCJOH+-UA at mail dot gmail dot com> <238543C3-39EA-4D5D-8C54-631BF796A38B at mac dot com>
On 27/03/16 06:57, Michael Clark wrote:
> GCC, Clang folk, any ideas on why there is a stack spill for a
> volatile register argument passed in esi? Does volatile force the
> argument to have storage allocated on the stack? Is this a corner
> case in the C standard? This argument in the x86_64 calling
> convention only has a register, so technically it canât change
> outside the control of the C "virtual machineâ so volatile has a
> vague meaning here.
"volatile" doesn't really mean very much, formally speaking. Sure, the
standard says "accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine," but nowhere
is it specified exactly what constitutes an access. (To be precise,
"what constitutes an access to an object that has volatile-qualified
type is implementation-defined.")
So, we have to fall back to tradition. Traditionally, all volatile
objects are allocated stack slots and all accesses to them are memory
accesses. This is consistent behaviour, and has been for a long time.
It is also extremely useful when debugging optimized code.
> volatile for scalar function arguments seems to mean: âmake this
> volatile and subject to change outside of the compilerâ rather than
> being a qualifier for its storage (which is a register).
No, arguments are not necessarily stored in registers: they're passed
in registers, but after function entry function they're just auto
variables and are stored wherever the compiler likes.