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

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

On Mon, Jul 4, 2016 at 12:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 01.07.16 at 18:20, <hjl.tools@gmail.com> wrote:
>> 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.
>
> Well, as almost always with leaving in place visibly wrong code,
> there is an issue with it, and I've just sent a patch with just that
> fix and respective tests added. I have to admit that I really dislike
> the attitude of waiting for issues to be run into when they can be
> dealt with proactively.
>

Nothing to deal with if we don't add new mnemonics to existing
instructions.

-- 
H.J.