RE: [PATCH] Support APX PUSHP/POPP

["Cui, Lili" <lili.cui@intel.com>]

> 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

Thanks,
Lili.