Re: GNU_PROPERTY_X86_* questions

[Jan Beulich <jbeulich at suse dot com>]

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:
>>>> - 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.

Coming back to this as I run into ambiguities here as I try to
make the behavior consistent (including actually covering all
insns). At the example of MOVQ2DQ and MOVDQ2Q: It seems clear that
both should record both MMX and XMM when used with only register
operands. But what about either insn used with a memory operand?
Somewhat similarly (ignoring the destination mask register for the
moment) for VFPCLASS with a memory operand.

IOW "processor states" is still ambiguous. My suggestion would be
to tie this (for SIMD and alike at least) to XCR0 bits. An insn
could record the most advanced of the bits that are required to
be set in XCR0 for it to not #UD. This would imply memory
operands to generally be treated the same as their corresponding
(for the same insn) register operands (CVTPI2PD being an
exception).

Yet this would still leave an open question: What about the high
16 [XY]MM registers? Should they record [XY]MM respectively, or
ZMM? According to the above suggested rule, _all_ EVEX encoded
AVX512 insns would have to record ZMM use.

If that's not the way to go, another question is that of insns
naming e.g. both an XMM and a YMM operand.

Bottom line - in order to get things sorted, a more precise set
of rules is needed first. As it stands, the recorded information
cannot be relied upon. This, to a fair part, is also because
testsuite coverage for this functionality is way too little
(and far below anything you would likely have asked me to
supply if I had contributed the functionality). I'm still trying
to make up my mind as to appropriate testing. Preferably I'd
like to have a way for the tests needed to get derived from the
opcode table, such that new additions will get automatically
covered (and the possible lack of code changes to tc-i386.c
detected).

Jan