public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"hubicka@ucw.cz" <hubicka@ucw.cz>
Subject: Re: [PATCH] x86-64: make "length_vex" also account for VEX.B use by register operand
Date: Fri, 3 Jun 2022 12:17:41 +0200	[thread overview]
Message-ID: <CAFULd4bo8+fFd4M25T9VkU5L8XRTaX=VPmSadbfqSAMRAkLOrg@mail.gmail.com> (raw)
In-Reply-To: <229d815d-41f4-69f1-50b1-e58001b24ba3@suse.com>

On Thu, Jun 2, 2022 at 5:11 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> The length attribute ought to be "the (bounding maximum) length of an
> instruction" according to the comment next to its definition. A register
> operand encoded using the ModR/M.rm field will additionally use VEX.B
> for encoding the highest bit of the register number. Hence for the high
> 8 GPR registers as well as the [xy]mm{8..15} ones 3-byte VEX encoding
> may be needed. Since it isn't known to the function calculating the
> length which register goes where in the insn encoding, be conservative
> and assume a 3-byte VEX prefix whenever any such register operand is
> present and there's no memory operand.
>
> gcc/
>
>         * config/i386/i386.cc (ix86_attr_length_vex_default): Take REX.B
>         into account for reg-only insns.

LGTM.

Thanks,
Uros.

> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -16820,7 +16820,8 @@ int
>  ix86_attr_length_vex_default (rtx_insn *insn, bool has_0f_opcode,
>                               bool has_vex_w)
>  {
> -  int i;
> +  int i, reg_only = 2 + 1;
> +  bool has_mem = false;
>
>    /* Only 0f opcode can use 2 byte VEX prefix and  VEX W bit uses 3
>       byte VEX prefix.  */
> @@ -16840,16 +16841,23 @@ ix86_attr_length_vex_default (rtx_insn *
>         if (GET_MODE (recog_data.operand[i]) == DImode
>             && GENERAL_REG_P (recog_data.operand[i]))
>           return 3 + 1;
> +
> +       /* REX.B bit requires 3-byte VEX. Right here we don't know which
> +          operand will be encoded using VEX.B, so be conservative.  */
> +       if (REX_INT_REGNO_P (recog_data.operand[i])
> +           || REX_SSE_REGNO_P (recog_data.operand[i]))
> +         reg_only = 3 + 1;
>        }
> -    else
> +    else if (MEM_P (recog_data.operand[i]))
>        {
>         /* REX.X or REX.B bits use 3 byte VEX prefix.  */
> -       if (MEM_P (recog_data.operand[i])
> -           && x86_extended_reg_mentioned_p (recog_data.operand[i]))
> +       if (x86_extended_reg_mentioned_p (recog_data.operand[i]))
>           return 3 + 1;
> +
> +       has_mem = true;
>        }
>
> -  return 2 + 1;
> +  return has_mem ? 2 + 1 : reg_only;
>  }
>
>
>

      reply	other threads:[~2022-06-03 10:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 15:11 Jan Beulich
2022-06-03 10:17 ` Uros Bizjak [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFULd4bo8+fFd4M25T9VkU5L8XRTaX=VPmSadbfqSAMRAkLOrg@mail.gmail.com' \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jbeulich@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).