<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2024, 10:39 PM Jan Beulich <<a href="mailto:jbeulich@suse.com">jbeulich@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27.06.2024 15:59, H.J. Lu wrote:<br>
> On Thu, Jun 27, 2024, 5:25 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br>
> <br>
>> On 27.06.2024 08:06, Kong, Lingling wrote:<br>
>>>> --- a/gas/config/tc-i386.c<br>
>>>> +++ b/gas/config/tc-i386.c<br>
>>>> @@ -7137,7 +7137,8 @@ md_assemble (char *line)<br>
>>>>              && i.base_reg<br>
>>>>              && i.base_reg->reg_num == RegIP<br>
>>>>              && i.tm.operand_types[0].bitfield.class == Reg<br>
>>>> -            && i.tm.operand_types[2].bitfield.class == Reg)<br>
>>>> +            && (i.tm.operand_types[2].bitfield.class == Reg<br>
>>>> +                || (i.tm.operands == 2 && <a href="http://i.tm.opcode_modifier.nf" rel="noreferrer noreferrer" target="_blank">i.tm.opcode_modifier.nf</a>)))<br>
>>>>            /* Allow APX: add %reg1, foo@gottpoff(%rip), %reg2.  */<br>
>>>>            break;<br>
>><br>
>> What does the <a href="http://i.tm.opcode_modifier.nf" rel="noreferrer noreferrer" target="_blank">i.tm.opcode_modifier.nf</a> check achieve here? All EVexMap4<br>
>> ADD forms permit {nf}. The comment also needs updating, to avoid it<br>
>> going further stale (it already hasn't been quite accurate). With the<br>
>> comment properly updated to list all permissible forms, I think you'll<br>
>> also note that what you add to the condition is too lax: Aiui<br>
>><br>
>>         add %rax, foo@GOTTPOFF(%rip)<br>
>><br>
>> is not supposed to be permitted (according to the testsuite additions<br>
>> you make).<br>
>><br>
>> Finally a question perhaps more for H.J. than for you: Why is it that<br>
>> ADD is special-cased here for the APX EVEX-encoded case, when there's<br>
>> no similar special casing for legacy encodings?<br>
> <br>
> ADD is the part of TLS sequence.<br>
<br>
I expected you would say that, but it doesn't answer my question: Why a<br>
special case for EVEX-encoded ADD but not a special case for legacy<br>
encoded ADD/MOV (and whatever else may be part of such a sequence).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The TLS sequences are parts of TLS ABI.  Linker may transform them</div><div dir="auto">to different sequences.  There is nothing to do for legacy encoding.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd also wonder, btw., whether CFCMOVcc or EVEX-encoded CMOVcc couldn't<br>
be a possible part of such a sequence, going forward.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">TLS ABI must be updated first.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jan<br>
</blockquote></div></div></div>