[PATCH v3 03/10] x86: move certain MOVSX/MOVZX tests

[Jan Beulich]

On 22.01.2020 17:09, H.J. Lu wrote:
> On Wed, Jan 22, 2020 at 8:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 20.01.2020 16:33, H.J. Lu wrote:
>>> On Mon, Jan 20, 2020 at 7:30 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 13.01.2020 18:33,  H.J. Lu  wrote:
>>>>> On Fri, Dec 27, 2019 at 1:24 AM Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>
>>>>>> Some encodings are about to gain a warning - move them from test cases
>>>>>> not expecting any diagnostics to the new, dedicated ones, to allow
>>>>>> better focus on the actual changes in the subsequent patch.
>>>>>>
>>>>>> The new tests added have some wrong expectations right now, which will
>>>>>> be corrected by the next patch. The test is being added here to make
>>>>>> more visible which cases actually were wrong (and hence get changed),
>>>>>> besides demonstrating that in the vast majority of cases the subsequent
>>>>>> change doesn't alter generated code.
>>>>>
>>>>> We can't change the encoding nor disallow it.  At most, we can issue a
>>>>> warning.   If it is the case, calling it "wrong" isn't accurate.
>>>>
>>>> If you look at the following patch you'll find that the two cases
>>>> where an encoding actually changes, this will then be accompanied
>>>
>>> Please open a bug for wrong encoding before we decide what to do
>>> about it.   At minimum, we need a record.
>>
>> Seeing you say "We should make them hard errors now." in that bug,
>> I hope it is clear that that's an orthogonal job, which - once
>> done - will convert what gets warned about in the next patch (i.e.
>> the cases where you're worried about encoding changes) into errors
>> at the same time. Hence I'd like to ask what the disposition of
>> this and the next patch is: With your cited remark in the bug, I
>> don't see what adjustments you want to see done here. IOW it would
>> seem to me that both patches could go in as they are.
> 
> All MOVZX with incorrect operands should be hard errors in
> 16-bit, 32-bit and 64-bit modes.

Only once other insns behave in a similar way. Programmers should
be able to predict assembler behavior, and hence derive what'll
happen for one insn/operands combination from what happens from
any other, sufficiently similar one. This is what the patch helps
with. The consistency in behavior won't be broken down the road
when you or someone else switches the behavior you talk about
from being warnings to being errors. But it can't be the purpose
of this (or any) patch to introduce special cases for certain
insns when none are warranted. In fact we should try to reduce
the number of special cases (which I think I'm slowly making
progress with, see e.g. the change to md_assemble() by patch 4,
which, yes, unavoidably comes with the need to insert less
arbitrary special casing code in process_suffix()).

If you make the change you've outlined, I'll be happy to re-base
the patches here on top, which will merely mean adjustments to
the testsuite additions. If, however, said change will take time,
then may I please get approval to get in the two patches here?

Jan