[3/6,i386] Remove machine_function::call_ms2sysv_pad_out

The -mcall-ms2sysv-xlogues project added the boolean fields
call_ms2sysv_pad_in and call_ms2sysv_pad_out to struct machine_function
to track rather or not an additional 8 bytes of padding was needed for
stack alignment prior to and after the stub save area.  This design was
based upon the faulty assumption the function body would not require a
stack alignment greater than 16 bytes.  This continues to work well for
managing padding prior to the stub save area, but will not work for the
outgoing alignment.

Rather than changing machine_function::call_ms2sysv_pad_out to a larger
type, this patch removes it, thus transferring responsibility for stack
alignment following the stub save area from class xlogue_layout to the
body of ix86_compute_frame_layout.  Since the 64-bit va_arg register
save area is always a multiple of 16-bytes in size (176 for System V ABI
and 96 for Microsoft ABI), the ROUND_UP calculation for the stack offset
at the start of the function body (frame.frame_pointer_offset) will
assure there is enough room for any padding needed to keep the save area
for SSE va_args 16-byte aligned, so no modification is needed for that
calculation.

Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
---
 gcc/config/i386/i386.c | 18 ++++--------------
 gcc/config/i386/i386.h |  8 ++------
 2 files changed, 6 insertions(+), 20 deletions(-)

On Mon, Jul 31, 2017 at 1:24 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
> The -mcall-ms2sysv-xlogues project added the boolean fields
> call_ms2sysv_pad_in and call_ms2sysv_pad_out to struct machine_function
> to track rather or not an additional 8 bytes of padding was needed for
> stack alignment prior to and after the stub save area.  This design was
> based upon the faulty assumption the function body would not require a
> stack alignment greater than 16 bytes.  This continues to work well for
> managing padding prior to the stub save area, but will not work for the
> outgoing alignment.
>
> Rather than changing machine_function::call_ms2sysv_pad_out to a larger
> type, this patch removes it, thus transferring responsibility for stack
> alignment following the stub save area from class xlogue_layout to the
> body of ix86_compute_frame_layout.  Since the 64-bit va_arg register
> save area is always a multiple of 16-bytes in size (176 for System V ABI
> and 96 for Microsoft ABI), the ROUND_UP calculation for the stack offset
> at the start of the function body (frame.frame_pointer_offset) will
> assure there is enough room for any padding needed to keep the save area
> for SSE va_args 16-byte aligned, so no modification is needed for that
> calculation.
>
> Signed-off-by: Daniel Santos <daniel.santos@pobox.com>

LGTM.

OK for mainline.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386.c | 18 ++++--------------
>  gcc/config/i386/i386.h |  8 ++------
>  2 files changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 47c5608c3cd..e2e9546a27c 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2491,9 +2491,7 @@ public:
>      unsigned last_reg = m->call_ms2sysv_extra_regs + MIN_REGS - 1;
>
>      gcc_assert (m->call_ms2sysv_extra_regs <= MAX_EXTRA_REGS);
> -    return m_regs[last_reg].offset
> -          + (m->call_ms2sysv_pad_out ? 8 : 0)
> -          + STUB_INDEX_OFFSET;
> +    return m_regs[last_reg].offset + STUB_INDEX_OFFSET;
>    }
>
>    /* Returns the offset for the base pointer used by the stub.  */
> @@ -12849,13 +12847,12 @@ ix86_compute_frame_layout (void)
>         {
>           unsigned count = xlogue_layout::count_stub_managed_regs ();
>           m->call_ms2sysv_extra_regs = count - xlogue_layout::MIN_REGS;
> +         m->call_ms2sysv_pad_in = 0;
>         }
>      }
>
>    frame->nregs = ix86_nsaved_regs ();
>    frame->nsseregs = ix86_nsaved_sseregs ();
> -  m->call_ms2sysv_pad_in = 0;
> -  m->call_ms2sysv_pad_out = 0;
>
>    /* 64-bit MS ABI seem to require stack alignment to be always 16,
>       except for function prologues, leaf functions and when the defult
> @@ -12957,15 +12954,7 @@ ix86_compute_frame_layout (void)
>        gcc_assert (!frame->nsseregs);
>
>        m->call_ms2sysv_pad_in = !!(offset & UNITS_PER_WORD);
> -
> -      /* Select an appropriate layout for incoming stack offset.  */
> -      const struct xlogue_layout &xlogue = xlogue_layout::get_instance ();
> -
> -      if ((offset + xlogue.get_stack_space_used ()) & UNITS_PER_WORD)
> -       m->call_ms2sysv_pad_out = 1;
> -
> -      offset += xlogue.get_stack_space_used ();
> -      gcc_assert (!(offset & 0xf));
> +      offset += xlogue_layout::get_instance ().get_stack_space_used ();
>      }
>
>    /* Align and set SSE register save area.  */
> @@ -12993,6 +12982,7 @@ ix86_compute_frame_layout (void)
>
>    /* Align start of frame for local function.  */
>    if (stack_realign_fp
> +      || m->call_ms2sysv
>        || offset != frame->sse_reg_save_offset
>        || size != 0
>        || !crtl->is_leaf
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 1648bdf1556..b08e45f68d4 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -2646,17 +2646,13 @@ struct GTY(()) machine_function {
>    BOOL_BITFIELD arg_reg_available : 1;
>
>    /* If true, we're out-of-lining reg save/restore for regs clobbered
> -     by ms_abi functions calling a sysv function.  */
> +     by 64-bit ms_abi functions calling a sysv_abi function.  */
>    BOOL_BITFIELD call_ms2sysv : 1;
>
>    /* If true, the incoming 16-byte aligned stack has an offset (of 8) and
> -     needs padding.  */
> +     needs padding prior to out-of-line stub save/restore area.  */
>    BOOL_BITFIELD call_ms2sysv_pad_in : 1;
>
> -  /* If true, the size of the stub save area plus inline int reg saves will
> -     result in an 8 byte offset, so needs padding.  */
> -  BOOL_BITFIELD call_ms2sysv_pad_out : 1;
> -
>    /* This is the number of extra registers saved by stub (valid range is
>       0-6). Each additional register is only saved/restored by the stubs
>       if all successive ones are. (Will always be zero when using a hard
> --
> 2.13.3
>