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

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 23.02.17 at 17:20, <hjl.tools@gmail.com> wrote:
> On Thu, Feb 23, 2017 at 8:13 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.02.17 at 16:58, <hjl.tools@gmail.com> wrote:
>>> On Thu, Feb 23, 2017 at 4:40 AM, Jan Beulich <JBeulich@suse.com> 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.

Jan