Re: [PATCH] mips/o32: fix internal_syscall5/6/7

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 16 Aug 2017, Maciej W. Rozycki wrote:

> On Tue, 15 Aug 2017, Joseph Myers wrote:
> 
> > In which case having a volatile integer variable with value 4, declaring a 
> > VLA whose size is that variable, and storing a pointer to that VLA in a 
> > variable, would be an alternative to alloca to force a frame pointer, but 
> > with deallocation happening when the scope ends rather than the function 
> > ending (and the syscall macro has its own scope, so using it inside a loop 
> > wouldn't be a problem).
> 
>  I suspect using volatile variables will cause unnecessary memory traffic.  
> Passing the size specifier through an empty `asm' might give better code; 
> also I think we can use 0 as the size requested, not to decrease the stack 
> pointer unnecessarily, e.g.:

Sure, as long as (a) the compiler can't know the size is actually constant 
and (b) it can't know the VLA isn't actually used, as if it can tell 
either of those things it can optimize away the variable stack allocation.

>  Also I wonder if there's actually a dependable way to have GCC itself 
> allocate the argument space we require.  For example if we set `s' to 1 
> above instead for `internal_syscall6', then would `0($sp)' and `4($sp)' be 
> valid to place arguments #5 and #6 at respectively without the subsequent 
> $sp adjustment we currently have in the syscall `asm' or would it be UB?

You can't tell whether the compiler might have allocated other variables 
on the stack after the dynamic adjustment - that is, whether any 
particular offset from sp is in fact unused or not.

-- 
Joseph S. Myers
joseph@codesourcery.com