Re: [PATCH] x86-64: Support APX NF TLS IE with 2 operands

[Jan Beulich <jbeulich@suse.com>]

On 03.07.2024 12:01, Hongyu Wang wrote:
> Jan Beulich <jbeulich@suse.com> 于2024年7月3日周三 17:23写道：
>>
>> On 03.07.2024 09:49, H.J. Lu wrote:
>>> Have I missed something? I haven't seen any testcases.
>>
>> From my description you could have made one yourself, if you really didn't
>> believe what I was saying. Here you go:
>>
>>         .text
>> gottpoff:
>>         .irp op, add, sub
>>         \op     foo@gottpoff(%rip), %rax
>>         \op     foo@gottpoff(%rip), %r16
>>         \op     foo@gottpoff(%rip), %rax, %rcx
>>         \op     %rax, foo@gottpoff(%rip), %rcx
>>         {nf} \op foo@gottpoff(%rip), %rax
>>         .endr
>>
>>         popcnt  foo@gottpoff(%rip), %rax
>>         popcnt  foo@gottpoff(%rip), %r16
>>         {nf} popcnt foo@gottpoff(%rip), %rax
>>
>>         adox    foo@gottpoff(%rip), %rax
>>         adox    foo@gottpoff(%rip), %r16
>>
> 
> These instructions are actually allowed with the newly added
> relocation type R_X86_64_CODE_{5,6}_GOTTPOFF, but there is no chance
> for compiler to generate such code in TLS sequence.
> I'm not sure how the logic can be simplified, we still need to check
> for each operands for the allowed case, while we can add more ops
> other than just MN_add.

Why would operands need checking? Why would they not need checking in
the legacy encoding case? My present plan is to simply permit anything
in EVEX map 4. Unless of course we want to tighten what's permitted as
legacy encodings.

Jan