[SLOF] [PATCH 3/4] fbuffer: Implement MRMOVE as an accelerated primitive

[Segher Boessenkool]

On Mon, Sep 14, 2015 at 12:10:51PM +0200, Thomas Huth wrote:
> >> The code saves r31 to a negative stack offset, without decrementing r1,
> >> and then jumps to c_romfs_lookup. That assembler function then saves
> >> some more registers on the stack and thus destroys the save-area of
> >> r31.
> >>
> >> Why is GCC doing this? It sounds weird that it does not decrement r1
> >> before going into the inline-assembler code...?
> > 
> > It is perfectly valid -- that is, if this is a leaf function, so it
> > doesn't call anything.  And GCC does not know any better :-(
> 
> Ah, I was not aware of this paragraph in the ABI:
> 
> "The 288 bytes below the stack pointer is available as volatile storage
> which is not preserved across function calls. ..."
> 
> (http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#STACK)
> 
> ... sounds non-intuitive at a first glance, but ok, it makes sense from
> a performance point of view.

It's informally called the "red zone"; many ABIs have it, e.g. x86-64 ELF.
Many other ABIs do not have it, it is such a headache :-)


Segher