Re: [PATCH 4/7] x86: improve match_template()'s diagnostics

[Jan Beulich <jbeulich@suse.com>]

On 17.08.2022 22:24, H.J. Lu wrote:
> On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> At the example of
>>
>>         extractps $0, %xmm0, %xmm0
>>         insertps $0, %xmm0, %eax
>>
>> (both having respectively the same mistake of using the wrong kind of
>> destination register) it is easy to see that current behavior is far
>> from ideal: The former results in "unsupported instruction" for 32-bit
>> code simply because the 2nd template we have is a Cpu64 one. Instead we
>> should aim at emitting the "best" possible error, which will typically
>> be the one where we passed the largest number of checks. Generalize the
>> original "specific_error" approach by making it apply to the entire
>> matching loop, utilizing that line numbers increase as we pass further
>> checks.
>> ---
>> As to the inval-tls testcase: Why is KMOV special? Are e.g. VMOV or
>> other vector insns (legacy or EVEX-encoded) any different? Shouldn't the
>> use of the respective reloc types be limited to _exactly_ the insns they
>> are intended to be used with? Furthermore having this check in
>> match_template() is unhelpful, as the resulting diagnostic isn't aiding
>> in understanding what's wrong. Template matching should be left alone
>> here, and the issue be diagnosed later, say directly in md_assemble()
>> (alongside the various further consistency checks there) or in
>> process_operands().
> 
> GCC may generate invalid TLS code sequences with KMOV, not other
> instructions.  We want to catch them by assembler.   It is easier to disallow
> the invalid instructions.

I did actually check both the discussion and gcc code in question, and I
was not able to prove that it could have done so only for KMOV. And yes,
I agree with disallowing the invalid instructions. The question is why
we do so only for a limited and inconsistent subset.

In addition you don't say anything regarding the point in time when we
diagnose this, the placement of which - as said - looks sub-optimal to me.

Jan