[PATCH 3/6] x86: harmonize disp with imm handling

[Jan Beulich]

On 21.06.2021 15:26, H.J. Lu wrote:
> On Sun, Jun 20, 2021 at 11:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 18.06.2021 17:41, H.J. Lu wrote:
>>> On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 18.06.2021 16:12, H.J. Lu wrote:
>>>>> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 17.06.2021 18:12, H.J. Lu wrote:
>>>>>>> On Thu, Jun 17, 2021 at 9:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 17.06.2021 18:00, H.J. Lu wrote:
>>>>>>>>> On Thu, Jun 17, 2021 at 7:57 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 17.06.2021 16:46, H.J. Lu wrote:
>>>>>>>>>>> On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>> +++ b/gas/testsuite/gas/i386/disp-imm-32.s
>>>>>>>>>>>> @@ -0,0 +1,17 @@
>>>>>>>>>>>> +       .text
>>>>>>>>>>>> +disp_imm:
>>>>>>>>>>>> +       mov     -0xffffffff(%eax), %eax
>>>>>>>>>>>
>>>>>>>>>>> I don't think we should treat  -0xffffffff(%eax) as 1(%eax).
>>>>>>>>>>> We allow addresses to wraparound. I don't see a need for
>>>>>>>>>>> displacements to wraparound.
>>>>>>>>>>
>>>>>>>>>> This then is entirely unexpected to the programmer. In fact the
>>>>>>>>>> same (abstracted away behind some defines or equates) constant
>>>>>>>>>> could be used for both purposes (and should be usable both ways,
>>>>>>>>>> imo).
>>>>>>>>>
>>>>>>>>> Since hardware wraparound on DISP + BASE + INDEX * SCALE, not
>>>>>>>>> on DISP, it is wrong to change DISP + BASE + INDEX * SCALE to
>>>>>>>>> wraparound (DISP) + BASE + INDEX * SCALE.
>>>>>>>>
>>>>>>>> But this is true regardless of how small (or big) the displacement.
>>>>>>>> Without knowing the register values, you can't know at what
>>>>>>>> displacement values wraparound occurs. Also, unless I'm mistaken,
>>>>>>>> wrapround(a + b) == wrapround(wrapround(a) + wrapround(b)).
>>>>>>>
>>>>>>> Hardware does wraparound (DISP + BASE + INDEX * SCALE).
>>>>>>> Assembler and linker should only wraparound on the final address.
>>>>>>
>>>>>> I'm afraid this last sentence makes no sense to me: The assembler
>>>>>> (or linker) can't know the final address. Instead, both immediates
>>>>>> and displacements should allow for anything the programmer might
>>>>>> sensibly use. If 0xffffffff as a displacement is fine (meaning
>>>>>> -1 really), -0xffffffff (meaning 1) ought to be, too. Or else
>>>>>> where do you draw the boundary of which displacements are
>>>>>> "legitimate" and which are not?
>>>>>
>>>>> If the program wants 1, use 1.
>>>>
>>>> You realize that for the purpose of the test case the -0xffffffff is
>>>> an over-simplification of what might appear in "real" code, don't
>>>> you? It also feels as if you didn't really read my earlier remark:
>>>
>>> I don't think treating -0xffffffff as 1 here helps anyone.
>>
>> I'm afraid I was utterly mislead by your commentary here. There's no
>> change from this patch in the numeric meaning of -0xffffffff. The
>> change here is what warnings result and what encodings get used. As
>> the description says:
>>
>> 'Certain disp values may trigger "... shortened to ..." warnings when
>>  equivalent imm ones don't. In some of the cases there are also
>>  differences (for non-64-bit code) between BFD64 and !BFD64 builds. The
>>  resulting encodings (i.e. use [or not] of the shorter disp8 / imm8
>>  forms) are also different in some cases. Make this handling consistent.'
>>
>> Please may I ask that you take the new testcase and observe the
>> difference in behavior with / without BFD64 prior to this patch, and
>> the now consistent one?
> 
> Make disp consistent is good.  But wraparound disp is not.

You still didn't understand, it seems: This wrapping was there before.
All I did is make it consistently silent, and generate consistent code.

>   Please find another way to make disp consistent.

I don't see any.

Jan