This is the mail archive of the binutils@sourceware.org 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 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).
>
> Jan

We shouldn't change the meaning of existing REX prefixes.  Let's
leave Intel mode alone for now.


-- 
H.J.


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