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

[Craig Topper]

Sounds good to me. Thanks for looking into it more.

On Thu, Jun 25, 2015 at 2:08 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
wrote:

> 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
>



-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150625/dc3f2b53/attachment.html>