Re: GNU_PROPERTY_X86_* questions

[Jan Beulich <jbeulich at suse dot com>]

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.

> 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

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

Jan