This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNU_PROPERTY_X86_* questions


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.

The more useful one is the feature property.   SSE2 instructions can
use MMX registers.   Marking SSE used doesn't mean MMX is used.

> > BTW, ZMM register usage implies mask register usage.
>
> I did imply this, but it's not being said anywhere.
>



-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]