[PATCH 4/5] x86-64: Intel64 adjustments for conditional jumps

Thu Jul 16 09:53:25 GMT 2020

On 15.07.2020 16:02, H.J. Lu wrote:
> On Tue, Jul 14, 2020 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.07.2020 14:59, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 5:47 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.07.2020 14:36, H.J. Lu wrote:
>>>>> On Tue, Jul 14, 2020 at 5:20 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.07.2020 14:18, Jan Beulich wrote:
>>>>>>> On 14.07.2020 14:00, H.J. Lu wrote:
>>>>>>>> On Tue, Jul 14, 2020 at 3:13 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>> --- a/gas/testsuite/gas/i386/opcode-suffix.d
>>>>>>>>> +++ b/gas/testsuite/gas/i386/opcode-suffix.d
>>>>>>>>> @@ -305,22 +305,22 @@ Disassembly of section .text:
>>>>>>>>>   *[0-9a-f]+:   0f 77[  ]+emms[         ]+
>>>>>>>>>   *[0-9a-f]+:   0f 7e 90 90 90 90 90[   ]+movd[         ]+%mm2,-0x6f6f6f70\(%eax\)
>>>>>>>>>   *[0-9a-f]+:   0f 7f 90 90 90 90 90[   ]+movq[         ]+%mm2,-0x6f6f6f70\(%eax\)
>>>>>>>>> - *[0-9a-f]+:   0f 80 90 90 90 90[      ]+jo[   ]+909094e2 <foo\+0x909094e2>
>>>>>>>>> - *[0-9a-f]+:   0f 81 90 90 90 90[      ]+jno[  ]+909094e8 <foo\+0x909094e8>
>>>>>>>>> - *[0-9a-f]+:   0f 82 90 90 90 90[      ]+jb[   ]+909094ee <foo\+0x909094ee>
>>>>>>>>> - *[0-9a-f]+:   0f 83 90 90 90 90[      ]+jae[  ]+909094f4 <foo\+0x909094f4>
>>>>>>>>> - *[0-9a-f]+:   0f 84 90 90 90 90[      ]+je[   ]+909094fa <foo\+0x909094fa>
>>>>>>>>> - *[0-9a-f]+:   0f 85 90 90 90 90[      ]+jne[  ]+90909500 <foo\+0x90909500>
>>>>>>>>> - *[0-9a-f]+:   0f 86 90 90 90 90[      ]+jbe[  ]+90909506 <foo\+0x90909506>
>>>>>>>>> - *[0-9a-f]+:   0f 87 90 90 90 90[      ]+ja[   ]+9090950c <foo\+0x9090950c>
>>>>>>>>> - *[0-9a-f]+:   0f 88 90 90 90 90[      ]+js[   ]+90909512 <foo\+0x90909512>
>>>>>>>>> - *[0-9a-f]+:   0f 89 90 90 90 90[      ]+jns[  ]+90909518 <foo\+0x90909518>
>>>>>>>>> - *[0-9a-f]+:   0f 8a 90 90 90 90[      ]+jp[   ]+9090951e <foo\+0x9090951e>
>>>>>>>>> - *[0-9a-f]+:   0f 8b 90 90 90 90[      ]+jnp[  ]+90909524 <foo\+0x90909524>
>>>>>>>>> - *[0-9a-f]+:   0f 8c 90 90 90 90[      ]+jl[   ]+9090952a <foo\+0x9090952a>
>>>>>>>>> - *[0-9a-f]+:   0f 8d 90 90 90 90[      ]+jge[  ]+90909530 <foo\+0x90909530>
>>>>>>>>> - *[0-9a-f]+:   0f 8e 90 90 90 90[      ]+jle[  ]+90909536 <foo\+0x90909536>
>>>>>>>>> - *[0-9a-f]+:   0f 8f 90 90 90 90[      ]+jg[   ]+9090953c <foo\+0x9090953c>
>>>>>>>>> + *[0-9a-f]+:   0f 80 90 90 90 90[      ]+jol[  ]+909094e2 <foo\+0x909094e2>
>>>>>>>>> + *[0-9a-f]+:   0f 81 90 90 90 90[      ]+jnol[         ]+909094e8 <foo\+0x909094e8>
>>>>>>>>> + *[0-9a-f]+:   0f 82 90 90 90 90[      ]+jbl[  ]+909094ee <foo\+0x909094ee>
>>>>>>>>> + *[0-9a-f]+:   0f 83 90 90 90 90[      ]+jael[         ]+909094f4 <foo\+0x909094f4>
>>>>>>>>> + *[0-9a-f]+:   0f 84 90 90 90 90[      ]+jel[  ]+909094fa <foo\+0x909094fa>
>>>>>>>>> + *[0-9a-f]+:   0f 85 90 90 90 90[      ]+jnel[         ]+90909500 <foo\+0x90909500>
>>>>>>>>> + *[0-9a-f]+:   0f 86 90 90 90 90[      ]+jbel[         ]+90909506 <foo\+0x90909506>
>>>>>>>>> + *[0-9a-f]+:   0f 87 90 90 90 90[      ]+jal[  ]+9090950c <foo\+0x9090950c>
>>>>>>>>> + *[0-9a-f]+:   0f 88 90 90 90 90[      ]+jsl[  ]+90909512 <foo\+0x90909512>
>>>>>>>>> + *[0-9a-f]+:   0f 89 90 90 90 90[      ]+jnsl[         ]+90909518 <foo\+0x90909518>
>>>>>>>>> + *[0-9a-f]+:   0f 8a 90 90 90 90[      ]+jpl[  ]+9090951e <foo\+0x9090951e>
>>>>>>>>> + *[0-9a-f]+:   0f 8b 90 90 90 90[      ]+jnpl[         ]+90909524 <foo\+0x90909524>
>>>>>>>>> + *[0-9a-f]+:   0f 8c 90 90 90 90[      ]+jll[  ]+9090952a <foo\+0x9090952a>
>>>>>>>>> + *[0-9a-f]+:   0f 8d 90 90 90 90[      ]+jgel[         ]+90909530 <foo\+0x90909530>
>>>>>>>>> + *[0-9a-f]+:   0f 8e 90 90 90 90[      ]+jlel[         ]+90909536 <foo\+0x90909536>
>>>>>>>>> + *[0-9a-f]+:   0f 8f 90 90 90 90[      ]+jgl[  ]+9090953c <foo\+0x9090953c>
>>>>>>>>>   *[0-9a-f]+:   0f 90 80 90 90 90 90[   ]+seto[         ]+-0x6f6f6f70\(%eax\)
>>>>>>>>>   *[0-9a-f]+:   0f 91 80 90 90 90 90[   ]+setno[        ]+-0x6f6f6f70\(%eax\)
>>>>>>>>>   *[0-9a-f]+:   0f 92 80 90 90 90 90[   ]+setb[         ]+-0x6f6f6f70\(%eax\)
>>>>>>>>
>>>>>>>> There are instructions like jl and jnl.  Will assembler properly
>>>>>>>> handle `l' as a suffix here?
>>>>>>>
>>>>>>> j<cc> as well as jmp (with displacement) have No_lSuf set, so won't
>>>>>>> accept l suffixes (same for the w one). Nevertheless already prior
>>>>>>> to this change the disassembler will produce "jmpl" (and "jmpw").
>>>>>>> IOW a disagreement between disassembler and assembler already exists.
>>>>>
>>>>> We should avoid it as much as we can.
>>>>>
>>>>>>>> If we do need to distinguish them, can we generate {disp32} pseudo prefix
>>>>>>>> instead?
>>>>>>>
>>>>>>> We could, but then consistently for Jcc, JMP, and CALL. But how is
>>>>>>> emitting a pseudo-prefix in line with the name of the controlling
>>>>>>> command line option "-Msuffix"?
>>>>>
>>>>> That works for me.
>>>>
>>>> Okay, but you didn't answer my question.
>>>
>>> We can always generate pseudo prefix.
>>
>> But my question was towards "prefix" != "suffix".
>>
>>>>>> FAOD to achieve consistency I think the preferred route would then
>>>>>> be for the assembler to accept l and w suffixes for Jcc and JMP.
>>>>>> Not sure though what fallout this may mean.
>>>>>
>>>>> That could be quite messy.
>>>>
>>>> I guess I'd still prefer to try that first, and resort to the
>>>> alternative only if it really turns out to be.
>>>
>>> Please give it a try.
>>>
>>>>>  I think pseudo prefix is much less invasive.
>>>>
>>>> Maybe to the disassembler; I'm less sure about the testsuites of both
>>>> gas and ld.
>>>>
>>>> Actually - if we were to go this route, then why pseudo prefixes in
>>>> the first place? We already emit data{16,32} prefixes for other
>>>> reasons, so we could do so here as well in place of the suffixes.
>>>
>>> There is data32 prefix.  But there is no disp32 prefix.  I call it
>>> pseudo prefix.
>>
>> But the prefix _is_ a data size override, i.e. data{16,32} _is_ what
>> we want to express. My question here is why to invent yet another
>> prefix when we already have a suitable one.
>>
> 
> We should use a prefix which can be processed by assembler.
> {dispXX} tells assembler to prefer a specific displacement size.

Funny you should say this: There's no {disp16}. And the assembler
understands (to a certain degree, but this got improved recently)
data16 / data32. IOW yet another argument towards data16 / data32,
if we are to go this route in the first place (which right now is
only the fallback in case allowing the suffixes in the assembler
causes overly difficult problems, and which continues to pend your
response to me pointing out that emitting _prefixes_ is not in
line with _suffix_ in -Msuffix).

Jan