[PATCH] Support APX PUSHP/POPP

[Jan Beulich]

On 29.11.2023 11:38, Cui, Lili wrote:
>>>>>>> --- a/gas/config/tc-i386.c
>>>>>>> +++ b/gas/config/tc-i386.c
>>>>>>> @@ -8715,6 +8715,13 @@ process_operands (void)
>>>>>>>        i.tm.operands++;
>>>>>>>      }
>>>>>>>
>>>>>>> +  /* PUSHP/POPP requires rex2.w == 1.  */  if (i.tm.mnem_off ==
>>>>>>> + MN_pushp || i.tm.mnem_off == MN_popp)
>>>>>>> +    {
>>>>>>> +      i.rex2_encoding = true;
>>>>>>> +      i.rex |= REX_W;
>>>>>>> +    }
>>>>>>
>>>>>> Well, I'm sorry for not considering JMPABS earlier on, but with
>>>>>> that also needing dealing with, I think I view my alternative
>>>>>> suggestion as
>>>> preferable.
>>>>>> That'll scale better when also considering that down the road
>>>>>> further such insns may appear. Whether it's actually
>>>>>> OperandConstraint that we leverage here is secondary (it's not
>>>>>> ideal because there's nothing
>>>> operand related here).
>>>>>> I'd be perfectly okay with some other attribute being suitably
>>>>>> overloaded, whereas I continue to think that introducing new
>>>>>> attributes should preferably be limited to either cases where more
>>>>>> than just two or three templates use them or cases where otherwise
>>>>>> it's impossible to avoid ambiguities. From earlier changes of mine
>>>>>> the underlying reason ought to be pretty clear: Each new attribute
>>>>>> consumes storage, and with thousands of templates growth of storage
>>>>>> requirements should be balanced with how frequently an attribute is
>>>>>> actually going to have a non-zero value. For example, with
>>>>>> is_evex_encoding() gone a brief inspection suggests that it might
>>>>>> be possible to overload Masking (or maybe Broadcast): They're
>>>>>> applicable to EVEX templates only, and the class of insns we're
>>>>>> discussing here is never going to be EVEX (or VEX). IOW not much
>>>>>> different from the overloading of StaticRounding. Such an overload
>>>>>> may then well be named Rex2 (as you had it, and considering its
>>>>>> intended use also for
>>>> JMPABS, plus taking into consideration that REX2.W will be set simply
>>>> because of the absence of NoRex64).
>>>>>>
>>>>>
>>>>> Haha, StaticRounding is really special, I tried "#define Rex2Req
>>>>> Masking" and
>>>> found that it will be used in i386-gen.c to identify EVEX
>>>> (Broadcast...), then I tried VexW and SIB found that they are all
>>>> used without precheck whether it was an vex instruction. Finally I
>>>> wanted to re-use StaticRounding and found out that hulin already uses it
>> for legacy insns.
>>>>
>>>> Hmm, I'm sorry for the trouble. I'm inclined to say OperandConstraint
>>>> with a new #define it is then.

Did you miss this before ...

>>>> Once everything's in I could then
>>>> still see whether I can
>>>> (reasonably) make e.g. Masking work here.
>>>>
>>>
>>> Then I will create a new attribute Rex2 for it.

... saying this and ...

>> ???
>>
> 
> I can't use "#define Rex2Req Masking" instead of creating a new bitfile for Rex2Req, then I have to create a new bitfile for Rex2Req , or you want to use i.tm.mnem_off to handle it? both are ok to me.

... this? IOW something along the lines of

#define Rex2              OperandConstraint=REX2

(REX2 may be too short a name for the necessary new #define).

And as indicated I'd subsequently see about reusing Masking (or some
other of the EVEX-only attributes) anyway.

Jan