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

[Maciej W. Rozycki]

On Wed, 16 Aug 2017, Joseph Myers wrote:

> >  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.

 Well, an `asm' is a black box, unless it is known -- under the conditions 
set out in GCC documentation -- to be safe to optimise away regardless.  
Neither `asm' I proposed matches the conditions.

> >  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.

 Hmm, taking the requirement to deallocate the space arranged for a VLA at 
the exit of the containing block into account I think we can eliminate the 
possibility for the compiler to have allocated space for other variables 
as long as no other variable has been declared within the same block (or 
any nested one).

 Or am I missing anything here?  E.g. is the compiler allowed to spill 
random data to the stack at any time even in the absence of a matching 
variable declaration?  Or is it allowed to allocate space for a non-VLA 
variable that has been declared outside the block concerned, but the 
lifespan of which is contained within the block in this stack space rather 
than in the local frame?

 If the answer to any of these questions is "yes", then would factoring 
out the syscall `asm' along with the associated VLA declaration to a 
helper `always_inline' function help or would it not?

 I mean it is a tiny optimisation, but some syscalls are frequently 
called, so if we can avoid a waste of resources, then why not?

  Maciej