Re: [PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes

[Jan Beulich <jbeulich at suse dot com>]

On 10.08.2019 01:10,  H.J. Lu  wrote:
>  From assembly program and debug perspective, a suffix is very useful
> when there may be different memory operand sizes.   Allowing more
> cases without suffix isn't helping here.  We need a strong reason to
> do that.

I've given this very simple and (imo) pretty strong reason:
Consistency. Programmers ought to be able to deduce from observed
behavior on one insn how another, similar insns is going to be
treated by the assembler. Once again, simply compare un-patched
gas behavior for

	add	$1, (%eax)
	bt	$1, (%eax)

vs

	add	$0x89, (%eax)
	shl	$1, (%eax)
	shl	$2, (%eax)
	shl	%cl, (%eax)

This is simply unacceptable.

Having put together this series I think I've managed to (mostly)
understand why this is, but the pattern behind it has absolutely
nothing to do with how programmers should write their code.

I wouldn't, btw., mind if we uniformly rejected ambiguous insns,
but it was my understanding from the original discussion (a few
years back) that you wouldn't accept this.

In any event, may I remind you that during said earlier discussion
you had agreed to the underlying concept, including setting forth
acceptance criteria? I view it as entirely unreasonable that
you've made me invest quite a bit of time to fulfill those
criteria (and to get the patch, which as you can see has ended up
as a series) into a shape where the result is actually making
sense, just to find now that all of the sudden you mean to block
all of this work.

Jan