sigaltstack and cygwin

[Matthew Fluet]

> So, in linux, there is no
> restriction imposed on %esp due to signal handlers.  Right?

I believe so.

> It looks like there are some hardwired constants (transferRegs,
> frontier) that will need to be defined conditionally on whether this
> restriction is being imposed.  

Yup.  None of those constants are exported by the functor, so they are
safe to move into the actual generate-transfers function.  We'll just pay
for the allocation at each call, rather than having them be globally
allocated.  Alternatively, we could allocate both sets of constants
globally and then just select which set at each call to
generate-transfers.

> I also see the following in lots of
> places
>              Assembly.directive_assume
> 	     {assumes
> 	      = [{register = stackTopReg,
> 		  memloc = stackTop (),
> 		  weight = 1024,
> 		  sync = false,
> 		  reserve = false},
> 		 {register = frontierReg,
> 		  memloc = frontier (),
> 		  weight = 2048,
> 		  sync = false,
> 		  reserve = false}]},

Yeah.  I really should pull some of those out like I did with the
runtimeEntry and farEntry.  Also, you'll want to not unreserve %esp where
it wraps a Ccall (there is a second one in runtime transfer).

> Basically, I was thinking to add one more element to the assumes list
> for esp=cstackp (and changing frontierReg to some other register (any
> recommendations?)). 

I'd suggest %edi or %esi; I've gone back and forth with using those for
frontier and stackTop.  You'll also want to take which-ever one you use
out of the transferRegs list (that's the list of registers that psueo-regs
can use to be passes between basic blocks; it should't include any other
"reserved" registers).  %eax is reserved for indexing in a jump table.
That's probably a little restrictive, better would be to have
liveTransfers just exclude eax from blocks that look like they might be
targets of jump tables.  But, in event, don't use %eax.

> > We'll lose some performance due to extra spilling with less registers.
> 
> Right.  So my optimization still makes sense here -- only impose the
> restriction on programs that install signal handlers.  Some earlier
> pass in the backend will set a flag to true iff we are compiling for
> cygwin and the program uses signals handler.  The code in
> x86-generate-transfers will test this flag when setting up the
> assumes.

Ah, very good.