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

[Jan Beulich]

On 03.07.2024 14:37, Kong, Lingling wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, July 3, 2024 4:10 PM
>>
>> On 03.07.2024 09:58, Kong, Lingling wrote:
>>> (i.tm.operand_types[2].bitfield.class == Reg || i.tm.operands == 2))
>>> and (i.tm.operand_types[i.operands -1].bitfield.class ==Reg) are not equivalent.
>>> When i.operands = 2, i.tm.operand_types[1]. bitfield.class is not reg
>>> and should be mem,
>>
>> Funny you should say that: There's no class "mem". You have a point though, but
>> that's only indicating there are further issues here: It shouldn't be the template
>> that's being looked at, but the actual operands. I.e. i.types[] rather than
>> i.tm.operand_types[].
>>
>>> And it has been restricted i.mem_operands == 1 and i.tm.opcode_space ==
>> SPACE_EVEXMAP4 before.
>>
>> How does that help with a memory destination?
> 
> i.tm.operand_types[0].bitfield.class == Reg want to restrict a register destination.

"Want to" != "does". If the template allows for both memory and (whatever
kind of) register, .class will indicate the register kind. You can tell
whether the actual operand is a register only from looking at i.types[]
(or i.flags[])). Looking at i.tm.operand_types[] only helps when memory
isn't permitted there (and hence operand matching would have failed when
a memory operand is present in the given operand position).

Plus, btw, i.tm.operand_types[0] isn't describing the destination anyway,
but (one of) the source(s). Recall internal representation is following
AT&T syntax.

>>> And you said all EVexMap4 ADD forms permit {nf} is yes, so I removed
>>> the restriction for {nf},
>>> EVexMap4 is enough. The code here just handle the TLS IE with EVEX encoding.
>>> Does not affect legacy instructions.
>>
>> Then you didn't understand what I was saying. The problem is the very tight
>> restricting of APX EVEX encodings versus the very lax "all legacy encodings are
>> okay as long as they don't access a SIMD register".
> 
> My patch just supported and listed all TLS IE with EVEX encoding which these TLS sequence also supported in linker.
> The problem you mentioned does exist. It feels like a historical issue for undefined behavior. According to your
> expectations, either the gas for EVEX encoding should be more relaxed , or more strict for all legacy instructions.
> I don't know if I understand it correctly, although I prefer the latter. If you prefer the former, you can indeed modify
> this code.

Well. If it ends up being me to make this more consistent, I'd be relaxing
it. Unless of course good reasons are brought forward of why relaxing is a
bad idea. This is on the grounds of the assembler not being supposed to
needlessly restrict people in what they're doing. We should only reject
code if we _know_ it can't work, or if from what we get to see we can't
really conclude what is meant. This way we allow creative people to write
code we didn't even think about could be written.

If otoh somebody else, e.g. you, was taking care of the issue, then I also
wouldn't mind tightening, as long as proper justification is being provided.

Jan