🚀 go-pugleaf

On pre-V9 code, the stack is always aligned to a multiple of 8 bytes
(otherwise the kernel is within its rights to kill the process).
(In V9 code the alignment appears to jump to 16 bytes; however, I
am only compiling V8 code.)

This means that alloca() can "know" that the stack is properly aligned
at all times.  However, given code like:

	void f() { char *p = alloca(13); g(p); }

gcc 2.7.1 generates (under -O2; I am still compiling 2.7.1 with
itself at this moment):

	GNU C version 2.7.1 (sparc) compiled by GNU C version 2.6.3.
	gcc2_compiled.:
	___gnu_compiled_c:
	.text
		.align 4
		.global _f
		.proc   020
	_f:
		!#PROLOGUE# 0
		save %sp,-104,%sp
		!#PROLOGUE# 1
		add %sp,-112,%sp
		add %sp,99,%o0
		call _g,0
		and %o0,-8,%o0
		ret
		restore

Feeding the same code to gcc 2.6.3 (also -O2) produces:

	GNU C version 2.6.3 (sparc) compiled by GNU C version 2.6.3.
	gcc2_compiled.:
	___gnu_compiled_c:
	.text
		.align 4
		.global _f
		.proc   020
	_f:
		!#PROLOGUE# 0
		save %sp,-104,%sp
		!#PROLOGUE# 1
		add %sp,-112,%sp
		call _g,0
		add %sp,96,%o0
		ret
		restore

which is one instruction shorter.  It turns out that this occurs
for every alloca() call.

(Incidentally, it might be nice if the first `add' here could be
combined with the previous `save', though I doubt there are very
many places where this would have any real difference.)

I looked at the code in explow.c and am not really clear on what
is wrong here.  The sparc does define STACK_POINTER_OFFSET, so
the test (broken into several lines here):

	#if defined (STACK_DYNAMIC_OFFSET) || \
	    defined (STACK_POINTER_OFFSET) || \
	    defined (ALLOCATE_OUTGOING_ARGS) || \
	    ! defined (STACK_BOUNDARY)

succeeds and we define MUST_ALIGN as 1, rather than using the code
in the #else part (defining MUST_ALIGN as STACK_BOUNDARY <
BIGGEST_ALIGNMENT, which would always be 0 on the sparc).  I suspect
that when STACK_BOUNDARY is defined, it should be able to override
the other three macros, but there is a lot of code in here, and I
am not confident I could change it with any success.

Chris