[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 ahmed.bougacha at gmail.com
Tue Jun 23 14:20:46 PDT 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: application/octet-stream
Size: 8027 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150623/32313c3e/attachment.obj>


More information about the llvm-commits mailing list