x86: tighten condition for emitting LOCK on control register accesses

Message ID 5B0E55CC02000078001C6D8C@prv1-mh.provo.novell.com
State New
Headers show
Series
  • x86: tighten condition for emitting LOCK on control register accesses
Related show

Commit Message

Jan Beulich May 30, 2018, 7:42 a.m.
The control register is never expressed by REX.B; this bit only affects
the involved GPR. Also only one of the operands can have its "control"
flag set, so only check the correct operand.

gas/
2018-05-30  Jan Beulich  <jbeulich@suse.com>

	* config/tc-i386.c (build_modrm_byte): Drop REX_B from condition
	checking for the need of emitting LOCK. Check "control" bit just
	once.

Comments

H.J. Lu May 30, 2018, 12:36 p.m. | #1
On Wed, May 30, 2018 at 12:42 AM, Jan Beulich <JBeulich@suse.com> wrote:
> The control register is never expressed by REX.B; this bit only affects

> the involved GPR. Also only one of the operands can have its "control"

> flag set, so only check the correct operand.

>

> gas/

> 2018-05-30  Jan Beulich  <jbeulich@suse.com>

>

>         * config/tc-i386.c (build_modrm_byte): Drop REX_B from condition

>         checking for the need of emitting LOCK. Check "control" bit just

>         once.

>

> --- a/gas/config/tc-i386.c

> +++ b/gas/config/tc-i386.c

> @@ -6894,12 +6894,11 @@ build_modrm_byte (void)

>           if ((i.op[source].regs->reg_flags & RegVRex) != 0)

>             i.vrex |= REX_R;

>         }

> -      if (flag_code != CODE_64BIT && (i.rex & (REX_R | REX_B)))

> +      if (flag_code != CODE_64BIT && (i.rex & REX_R))

>         {

> -         if (!i.types[0].bitfield.control

> -             && !i.types[1].bitfield.control)

> +         if (!i.types[i.tm.operand_types[0].bitfield.regmem].bitfield.control)

>             abort ();

> -         i.rex &= ~(REX_R | REX_B);

> +         i.rex &= ~REX_R;

>           add_prefix (LOCK_PREFIX_OPCODE);

>         }

>      }

>


Does it have any impact on assembly code?


-- 
H.J.
Jan Beulich May 30, 2018, 2:24 p.m. | #2
>>> On 30.05.18 at 14:36, <hjl.tools@gmail.com> wrote:

> On Wed, May 30, 2018 at 12:42 AM, Jan Beulich <JBeulich@suse.com> wrote:

>> The control register is never expressed by REX.B; this bit only affects

>> the involved GPR. Also only one of the operands can have its "control"

>> flag set, so only check the correct operand.

>>

>> gas/

>> 2018-05-30  Jan Beulich  <jbeulich@suse.com>

>>

>>         * config/tc-i386.c (build_modrm_byte): Drop REX_B from condition

>>         checking for the need of emitting LOCK. Check "control" bit just

>>         once.

>>

>> --- a/gas/config/tc-i386.c

>> +++ b/gas/config/tc-i386.c

>> @@ -6894,12 +6894,11 @@ build_modrm_byte (void)

>>           if ((i.op[source].regs->reg_flags & RegVRex) != 0)

>>             i.vrex |= REX_R;

>>         }

>> -      if (flag_code != CODE_64BIT && (i.rex & (REX_R | REX_B)))

>> +      if (flag_code != CODE_64BIT && (i.rex & REX_R))

>>         {

>> -         if (!i.types[0].bitfield.control

>> -             && !i.types[1].bitfield.control)

>> +         if (!i.types[i.tm.operand_types[0].bitfield.regmem].bitfield.control)

>>             abort ();

>> -         i.rex &= ~(REX_R | REX_B);

>> +         i.rex &= ~REX_R;

>>           add_prefix (LOCK_PREFIX_OPCODE);

>>         }

>>      }

>>

> 

> Does it have any impact on assembly code?


No - it was simply pointless from the beginning to use the more lax
checking.

Jan
H.J. Lu May 30, 2018, 2:34 p.m. | #3
On Wed, May 30, 2018 at 7:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.05.18 at 14:36, <hjl.tools@gmail.com> wrote:

>> On Wed, May 30, 2018 at 12:42 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>> The control register is never expressed by REX.B; this bit only affects

>>> the involved GPR. Also only one of the operands can have its "control"

>>> flag set, so only check the correct operand.

>>>

>>> gas/

>>> 2018-05-30  Jan Beulich  <jbeulich@suse.com>

>>>

>>>         * config/tc-i386.c (build_modrm_byte): Drop REX_B from condition

>>>         checking for the need of emitting LOCK. Check "control" bit just

>>>         once.

>>>

>>> --- a/gas/config/tc-i386.c

>>> +++ b/gas/config/tc-i386.c

>>> @@ -6894,12 +6894,11 @@ build_modrm_byte (void)

>>>           if ((i.op[source].regs->reg_flags & RegVRex) != 0)

>>>             i.vrex |= REX_R;

>>>         }

>>> -      if (flag_code != CODE_64BIT && (i.rex & (REX_R | REX_B)))

>>> +      if (flag_code != CODE_64BIT && (i.rex & REX_R))

>>>         {

>>> -         if (!i.types[0].bitfield.control

>>> -             && !i.types[1].bitfield.control)

>>> +         if (!i.types[i.tm.operand_types[0].bitfield.regmem].bitfield.control)

>>>             abort ();

>>> -         i.rex &= ~(REX_R | REX_B);

>>> +         i.rex &= ~REX_R;

>>>           add_prefix (LOCK_PREFIX_OPCODE);

>>>         }

>>>      }

>>>

>>

>> Does it have any impact on assembly code?

>

> No - it was simply pointless from the beginning to use the more lax

> checking.

>


Patch is OK.

Thanks.

-- 
H.J.

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -6894,12 +6894,11 @@  build_modrm_byte (void)
 	  if ((i.op[source].regs->reg_flags & RegVRex) != 0)
 	    i.vrex |= REX_R;
 	}
-      if (flag_code != CODE_64BIT && (i.rex & (REX_R | REX_B)))
+      if (flag_code != CODE_64BIT && (i.rex & REX_R))
 	{
-	  if (!i.types[0].bitfield.control
-	      && !i.types[1].bitfield.control)
+	  if (!i.types[i.tm.operand_types[0].bitfield.regmem].bitfield.control)
 	    abort ();
-	  i.rex &= ~(REX_R | REX_B);
+	  i.rex &= ~REX_R;
 	  add_prefix (LOCK_PREFIX_OPCODE);
 	}
     }