Re: [Patch] Adjustments for Windows x64 SEH

[Richard Henderson <rth at redhat dot com>]

On 2012-06-18 05:22, Tristan Gingold wrote:
> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
> +     allocation is 4GB (add a safety guard for saved registers).  */
> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
> +    return true;

Elsewhere you say this is an upper bound for stack use by the prologue.
It's clearly a wild guess.  The maximum stack use is 10*sse + 8*int 
registers saved, which is a lot less than 4096.

That said, I'm ok with *using* 4096 so long that the comment clearly
states that it's a large over-estimate.  I do suggest, however, folding
this into the SEH_MAX_FRAME_SIZE value, and expanding on the comment
there.  I see no practical difference between 0x80000000 and 0x7fffe000
being the limit.

> +/* Output assembly code to get the establisher frame (Windows x64 only).
> +   This corresponds to what will be computed by Windows from Frame Register
> +   and Frame Register Offset fields of the UNWIND_INFO structure.  Since
> +   these values are computed very late (by ix86_expand_prologue), we cannot
> +   express this using only RTL.  */
> +
> +const char *
> +ix86_output_establisher_frame (rtx target)
> +{
> +  if (!frame_pointer_needed)
> +    {
> +      /* Note that we have advertized an lea operation.  */
> +      output_asm_insn ("lea{q}\t{0(%%rsp), %0|%0, 0[rsp]}", &target);
> +    }
> +  else
> +    {
> +      rtx xops[3];
> +      struct ix86_frame frame;
> +
> +      /* Recompute the frame layout here.  */
> +      ix86_compute_frame_layout (&frame);
> +
> +      /* Closely follow how the frame pointer is set in
> +	 ix86_expand_prologue.  */
> +      xops[0] = target;
> +      xops[1] = hard_frame_pointer_rtx;
> +      if (frame.hard_frame_pointer_offset == frame.reg_save_offset)
> +	xops[2] = GEN_INT (0);
> +      else
> +	xops[2] = GEN_INT (-(frame.stack_pointer_offset
> +			     - frame.hard_frame_pointer_offset));
> +      output_asm_insn ("lea{q}\t{%a2(%1), %0|%0, %a2[%1]}", xops);

This is what register elimination is for; the value substitution happens
during reload.

Now, one *could* add a new pseudo-hard-register for this (we support as
many register eliminations as needed), but before we do that we need to
decide if we can adjust the soft frame pointer to be the value required.
If so, you can then rely on the existing __builtin_frame_address.  Which
is a very attractive sounding solution.  I'm 99% moving the sfp will work.


r~