[PATCH] Support APX PUSHP/POPP

[Cui, Lili]

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

Ok

Thanks,
Lili.