[PATCH v2 5/9] x86: improve handling of insns with ambiguous operand sizes

[Jan Beulich]

On 29.10.2019 18:55,  H.J. Lu  wrote:
> On Mon, Oct 28, 2019 at 1:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> Commit b76bc5d54e ("x86: don't default variable shift count insns to
>> 8-bit operand size") pointed out a very bad case, but the underlying
>> problem is, as mentioned on various occasions, much larger: Silently
>> selecting a (nowhere documented afaict) certain default operand size
>> when there's no "sizing" suffix and no suitable register operand(s) is
>> simply dangerous (for the programmer to make mistakes).
>>
>> While in Intel syntax mode such mistakes already lead to an error (which
>> is going to remain that way), AT&T syntax mode now gains warnings in
>> such cases by default, which can be suppressed or promoted to an error
>> if so desired by the programmer. Furthermore at least general purpose
>> insns now consistently have a default applied (alongside the warning
>> emission), rather than accepting some and refusing others.
>>
>> No warnings are (as before) to be generated for "DefaultSize" insns as
>> well as ones acting on selector and other fixed-width values. The set of
>> "DefaultSize" ones gets slightly widened for the purposes here.
> 
> What is the advantage to add DefaultSize vs the alternative?

I don't know what alternative you refer to; if you mean some
hypothetical one, then the advantage of simply adding
DefaultSize as done here is likely that it allows to not add or
further complicate logic in tc-i386*.c. Furthermore the ones which
get the attribute added should have had it already before, if the
comment "default insn size depends on mode" is to be trusted.

Jan