[PATCH] Support APX PUSHP/POPP

[Jan Beulich]

On 29.11.2023 14:02, Cui, Lili wrote:
>> 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.
>>
> 
> Oh, I didn't understand OperandConstraint correctly. REX2 conflict with  "pseudopfx: rex2:REX2:APX_F", I changed it to REX2_PREFIX( or, REX_REQ ?).
> 
> #define Rex2              OperandConstraint=REX2_PREFIX

REX2_REQUIRED perhaps?

Jan