[llvm] r192567 - Allow pinsrw/pinsrb/pextrb/pextrw/movmskps/movmskpd/pmovmskb/extractps instructions to parse either GR32 or GR64 without resorting to duplicating instructions.

[Ahmed Bougacha]

On Wed, Jun 24, 2015 at 12:59 PM, Ahmed Bougacha
<ahmed.bougacha at gmail.com> wrote:
> On Tue, Jun 23, 2015 at 8:19 PM, Craig Topper <craig.topper at gmail.com> wrote:
>> I don't believe current versions of gas add a rex.w prefix for   extractps
>> $7, %xmm0, %rcx   so I think current behavior is consistent. I don't have
>> access to any other assemblers to test.
>
> True, it doesn't.  I also tried inline-asm given to icc, it doesn't
> either. However, the OS X as(1) (-v says based on "GNU assembler
> version 1.38") does.

I gave this some more thought, and tried xed (which also drops REX.W,
and in fact flat out refuses stuff like "pmovmskb rax xmm0").

Abandoning the change; let's stick with the current behavior.

-Ahmed

> -Ahmed
>
>> On Tue, Jun 23, 2015 at 2:20 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
>> wrote:
>>>
>>> How about something like the attached patch?
>>> I'd personally prefer having separate instructions: it's simpler with
>>> less special cases, and it makes the operand types a little easier to
>>> work with (admittedly not a concern for in-tree code, only stuff like
>>> "smart" disassemblers would use that).
>>>
>>> -Ahmed
>>>
>>> On Tue, Jun 23, 2015 at 11:45 AM, Ahmed Bougacha
>>> <ahmed.bougacha at gmail.com> wrote:
>>> > On Mon, Jun 22, 2015 at 11:29 PM, Craig Topper <craig.topper at gmail.com>
>>> > wrote:
>>> >> I think I agree, but I'd like to find a way to do this without
>>> >> duplicating
>>> >> the instructions again. Maybe we can keep the register encodings
>>> >> unmodified
>>> >> instead of calling getGR32FromGR64, then detect whether we need REX.W
>>> >> in the
>>> >> encoder? May need a new TSFlag to enable this behavior.
>>> >
>>> > Yes, that might work; I'll have a look.
>>> >
>>> > Thanks!
>>> > -Ahmed
>>> >
>>> >> On Mon, Jun 22, 2015 at 5:40 PM, Ahmed Bougacha
>>> >> <ahmed.bougacha at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi Craig,
>>> >>>
>>> >>> Forgive the necromancy, but I'm wondering if this is the right thing:
>>> >>> we remove users' freedom to pick encodings (used by some, for padding
>>> >>> and such), for no good reason: with this commit, generated code uses
>>> >>> GR32 encodings, even if the assembly explicitly specified a GR64
>>> >>> register.
>>> >>>
>>> >>> Of course, that's starting from assembly;  if the compiler generates
>>> >>> the larger equivalent encoding that should be fixed, but I don't think
>>> >>> that's ever the case, as AFAICT GR32 is preferred by the various
>>> >>> patterns.
>>> >>>
>>> >>> What do you think about restoring the previous behavior?
>>> >>> -Ahmed
>>
>>
>>
>>
>> --
>> ~Craig