GNU_PROPERTY_X86_* questions

[Jan Beulich]

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.

> BTW, ZMM register usage implies mask register usage.

I did imply this, but it's not being said anywhere.

Jan