[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 at gmail.com
Tue Jun 23 20:19:34 PDT 2015
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.
On Tue, Jun 23, 2015 at 2:20 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
> 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).
> 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>
> >> I think I agree, but I'd like to find a way to do this without
> >> the instructions again. Maybe we can keep the register encodings
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits