Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
Re: [PATCH] mips/o32: fix internal_syscall5/6/7
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
[8]ページ先頭