Re: [PATCH] x86: allow suffix-less sign-extending movsb, movsw, and movsl

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jul 1, 2016 at 9:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 01.07.16 at 18:14, <hjl.tools@gmail.com> wrote:
>> On Fri, Jul 1, 2016 at 9:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 01.07.16 at 18:07, <hjl.tools@gmail.com> wrote:
>>>> On Fri, Jul 1, 2016 at 8:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 01.07.16 at 17:23, <hjl.tools@gmail.com> wrote:
>>>>>> On Fri, Jul 1, 2016 at 8:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>> On 01.07.16 at 17:12, <hjl.tools@gmail.com> wrote:
>>>>>>>> On Fri, Jul 1, 2016 at 7:55 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>>>> On 01.07.16 at 16:24, <jonas-devlists@watlock.be> wrote:
>>>>>>>>>> So in the end, I guess the movzb/movzw change is fine, but this one is
>>>>>>>>>> not. It's in inherent inconsistency related to the ability of leaving
>>>>>>>>>> away the size suffixes in combination with the chosen mnemonics, it
>>>>>>>>>> seems.
>>>>>>>>>
>>>>>>>>> I do not understand what inconsistency you refer to here. The
>>>>>>>>> only inconsistency I can see is that one can't omit the suffixes
>>>>>>>>> from these three instructions, unlike any others with GPR
>>>>>>>>> operands.
>>>>>>>>
>>>>>>>> This mnemonic inconsistency comes from ISA and AT&T syntax.
>>>>>>>> But there are no issues now.
>>>>>>>
>>>>>>> There is - as said, I fell into the trap seeing "movzb" in source code
>>>>>>> and assuming I then could also use "movzw" or "movsb" (etc). I
>>>>>>> can certainly open a bug if that helps you re-consider.
>>>>>>
>>>>>> It is unfortunate.  But it won't lead to wrong instructions being used.
>>>>>
>>>>> So since I see that rational arguments won't lead anywhere here
>>>>> - would you at least allow in the fix for the bug that this change
>>>>> uncovered (the one hunk changing tc-i386.c), even if that also
>>>>> doesn't seem to cause any issues right now?
>>>>
>>>> Please open a bug report with a testcase.
>>>
>>> You're kidding? As said, the issue got uncovered only with the
>>> other adjustments here; I'm not aware of a case where this
>>> would cause a problem without the other changes, and I'm not
>>> going to spend a whole lot of time trying to figure a broken case.
>>
>> So there is no issue with the current code base?
>
> I'm not aware of one (other than the source looking wrong), but
> I can't say there is none.

I'd like to leave it alone unless there is an issue with assembly input.


-- 
H.J.