This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] x86: fix handling of 64-bit operand size VPCMPESTR{I,M}

>>> On 23.02.17 at 17:20, <> wrote:
> On Thu, Feb 23, 2017 at 8:13 AM, Jan Beulich <> wrote:
>>>>> On 23.02.17 at 16:58, <> wrote:
>>> On Thu, Feb 23, 2017 at 4:40 AM, Jan Beulich <> wrote:
>>>> Just like REX.W affects operand size of the implicit rAX/rDX inputs to
>>>> PCMPESTR{I,M}, VEX.W does for VPCMPESTR{I,M}. Allow Q or L suffixes on
>>>> the instructions for AT&T mode.
>>>> For Intel mode, however, suffixes aren't the preferred choice, so
>>>> build_vex_prefix() needs to not only honor internally specified REX
>>>> flags (converting them to their VEX equivalents), but also such
>>>> resulting from explicit REX* prefix uses. Also adjust
>>>> build_evex_prefix() for consistency.
>>> Please don't use EXISTING REX prefixes for this purpose.  A new
>>> prefix to control encoding is better, but it probably belongs to another
>>> patch.
>> I'm sorry, but I don't follow. If you want to go that route, we'll need
>> more than just one new prefix, and it would be far from clear where
>> to draw the boundary. Granted this would allow to address the
>> 32-/16-bit side of things at once, but no, I don't think I have the
>> time or energy to go that route (or else I would have done so right
>> away, instead of adding a remark to the description in this regard).
> We shouldn't change the meaning of existing REX prefixes.  Let's
> leave Intel mode alone for now.

While I disagree, in the interest of getting the bug here fixed at
least in some way, I've submitted v3 with the REX parts dropped.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]