Re: GNU_PROPERTY_X86_* questions

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Nov 4, 2019 at 2:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 31.10.2019 22:05, H.J. Lu wrote:
> > On Tue, Oct 29, 2019 at 2:37 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 28.10.2019 19:03, H.J. Lu wrote:
> >>> On Mon, Oct 28, 2019 at 9:37 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 28.10.2019 16:22, H.J. Lu wrote:
> >>>>> On Mon, Oct 28, 2019 at 8:09 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 28.10.2019 15:50,  H.J. Lu  wrote:
> >>>>>>> On Fri, Oct 25, 2019 at 8:05 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 10.10.2019 17:16,  H.J. Lu  wrote:
> >>>>>>>>> On Thu, Oct 10, 2019 at 6:33 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> H.J.,
> >>>>>>>>>>
> >>>>>>>>>> I think I'm seeing a number of issues with the handling of these
> >>>>>>>>>> properties in gas, but without the original commit referencing a
> >>>>>>>>>> specification I can't really determine if some or all of these
> >>>>>>>>>> are actually "working as designed".
> >>>>>>>>>>
> >>>>>>>>>> Some of the points are:
> >>>>>>>>>> - What is the actual meaning of a set bit? I.e. should e.g. -O
> >>>>>>>>>
> >>>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
> >>>>>>>>>
> >>>>>>>>>>   converting between ISAs actually be reflected in the produced
> >>>>>>>>>>   note?
> >>>>>>>>>
> >>>>>>>>> It records what are in the object file.
> >>>>>>>>>
> >>>>>>>>>> - What is the rule of ISAs to get (or not get) a flag defined?
> >>>>>>>>>>   E.g. why are there AVX, AVX2, and FMA flags, but no XOP nor
> >>>>>>>>>>   FMA4 ones?
> >>>>>>>>>
> >>>>>>>>> One can propose them.
> >>>>>>>>>
> >>>>>>>>>> - What is the rule of register sets getting feature flags
> >>>>>>>>>>   defined? E.g. why are there XMM etc flags but there's no mask
> >>>>>>>>>>   register one?
> >>>>>>>>>
> >>>>>>>>> One can propose them.
> >>>>>>>>
> >>>>>>>> The document above does not explain in any way what is supposed to
> >>>>>>>> force on the individual GNU_PROPERTY_X86_FEATURE_2_* flags. While
> >>>>>>>> one can reasonably deduce this for GNU_PROPERTY_X86_ISA_1_* (albeit
> >>>>>>>> there's at least one bug in gas), but not for these. IOW it in
> >>>>>>>> particular does not answer ...
> >>>>>>>>
> >>>>>>>>>> - What are the rules for the feature flags actually getting set?
> >>>>>>>>>>   I find it puzzling that there are straight use
> >>>>>>>>>>   i.has_reg{x,y,z}mm flags (which could be easily done away
> >>>>>>>>>>   with), but for MMX quite a bit of extra logic is involved.
> >>>>>>>>
> >>>>>>>> ... this question.
> >>>>>>>>
> >>>>>>>>> MMX is set for pure MMX related instructions.
> >>>>>>>>
> >>>>>>>> Which only shift the question to "what is a pure MMX related
> >>>>>>>> instruction". I'd assume one touching any MMX register. But I'd
> >>>>>>>> also assume the same for e.g. GNU_PROPERTY_X86_FEATURE_2_XMM wrt
> >>>>>>>> XMM registers, yet that's not spelled out anywhere. In turn only
> >>>>>>>> the _exact_ spelling of this determines if there are further gas
> >>>>>>>> bugs here.
> >>>>>>>
> >>>>>>> GNU_PROPERTY_X86_FEATURE_2 describes processor capabilities
> >>>>>>> in terms of processor states.
> >>>>>>
> >>>>>> I.e. processor registers? If so, how is e.g. FXSR different from
> >>>>>> X87+XMM, and how come there's a separate MMX when its state is a
> >>>>>> subset of X87? Further, if so, how come the MMX handling is more
> >>>>>> complicated than the XMM one? It should all be tied to what
> >>>>>> registers an insn uses then, shouldn't it?
> >>>>>
> >>>>> There is no requirement to use MMX when X87 or FXSR are used.
> >>>>> A program can use X87+XMM with XSAVE without using MMX nor
> >>>>> FXSR.
> >>>>
> >>>> A program (at the source level) has no control over the bits
> >>>> which get set, afaict.
> >>>
> >>> That is correct.
> >>>
> >>>>>> If I'm understanding your reply correctly, then at least for this
> >>>>>> item I think I can see a fairly clear picture of the conditions
> >>>>>> under which adding a new flag would make sense to be proposed.
> >>>>>> But the same continues to not be true for the ISA side of things.
> >>>>>
> >>>>> ISA is different.   One can use AVX ISA with XMM, but without YMM.
> >>>>
> >>>> Of course ISA is different. But I don't agree with your example
> >>>> (I can't immediately think of AVX insns not at least zeroing the
> >>>> high YMM parts), nor does your reply come anywhere close to
> >>>> formulating a firm (set of) rule(s) when adding a new ISA flag
> >>>> would be appropriate.
> >>>
> >>> The optional ISA bits aren't required.
> >>>
> >>>> H.J., may I please ask that you take the time and actually
> >>>> address the questions raised, either here or by way of
> >>>> clarifications to the psABI drafts? Once again, besides wanting
> >>>> to understand the concept here, firm criteria are necessary to
> >>>> determine whether some of the anomalies I'm observing are
> >>>> actually bugs.
> >>>>
> >>>
> >>> Here is the possible output of readelf -n:
> >>>
> >>> Displaying notes found in: .note.gnu.property
> >>>   Owner                Data size Description
> >>>   GNU                  0x00000030 NT_GNU_PROPERTY_TYPE_0
> >>>       Properties: x86 feature: IBT, SHSTK
> >>> x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
> >>> x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC
> >>>
> >>> It shows that the program
> >>>
> >>> 1.  Compatible with IBT and SHSTK.
> >>> 2.  Use CMOV, SSE, SSE2, AVX, AVX512F.
> >>> 3.  Use x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC.
> >>>
> >>> It doesn't mean that no other features are used nor these features
> >>> are required at run-time since since CPUID can be used to check
> >>> the processor features at run-time.
> >>
> >> All fine and understood (including the difference to their "needed"
> >> counterparts), but it still doesn't answer my question.
> >
> > The main motivation is to describe what is used in a program.  I started
> > with ISA propperty.   A ISA bit is set if it is set in any relocatable
> > inputs and the property is present in all relocatable inputs and the
> > property is present only if it is present in all relocatable inputs.
> >
> > BTW, to make GNU_PROPERTY_X86_ISA_1_USED to work correctly.
> > a new bit to the existing ISA should be added to the new ISA property so
> > that the missing ISA bit in the output by the old assembler doesn't mean
> > the output doesn't have the ISA.
> >
> > There is GNU_PROPERTY_X86_ISA_1_NEEDED property.   But some
> > ISAs only have a few instructions.  Program is most likely to use  CPUID
> > check before branching to a specific code path.  Adding such ISA bits may
> > not be very useful.
>
> Then let's start with the most apparent anomaly: The FMA and FMA4
> ISAs have about the same set of insns each. Why is there a flag
> for the former, but none for the latter? (The answer here shouldn't
> again be "it can be proposed", but sufficiently firm criteria why
> one was selected to have a bit, while the other was not.)
>
> A 2nd funny example is CMOV, which covers exactly one insn (not
> counting the sub-forms representing the various conditions that can
> be keyed off of). This is contrary to you saying "But some ISAs
> only have a few instructions", suggesting that such aren't
> worthwhile to have a separate flag.

It is less useful.

> > The more useful one is the feature property.   SSE2 instructions can
> > use MMX registers.   Marking SSE used doesn't mean MMX is used.
>
> This is ambiguous, so I'd like to ask for clarification: MMX can mean
> both an ISA and a register file. There's only a feature flag for it,
> yet as per

MMX ISA is less interesting.  MMX register is more interesting.

>       /* Don't set GNU_PROPERTY_X86_FEATURE_2_MMX for prefetchtXXX nor
>          Xfence instructions.  */
>       if (i.tm.base_opcode != 0xf18
>           && i.tm.base_opcode != 0xf0d
>           && i.tm.base_opcode != 0xfaef8
>           && (i.has_regmmx
>               || i.tm.cpu_flags.bitfield.cpummx
>               || i.tm.cpu_flags.bitfield.cpua3dnow
>               || i.tm.cpu_flags.bitfield.cpua3dnowa))
>         x86_feature_2_used |= GNU_PROPERTY_X86_FEATURE_2_MMX;
>
> it gets driven from (among others) the CpuMMX attribute, which is an
> ISA representation, not something tracking register use. Why is this
> not just i.has_regmmx plus coverage for EMMS/FEMMS?
>

Yes, this also works.

-- 
H.J.