Re: [PATCH] x86/Intel: SHLD/SHRD have dual meaning

[Hongtao Liu <crazylht@gmail.com>]

On Mon, Apr 22, 2024 at 4:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 22.04.2024 09:47, Hongtao Liu wrote:
> > On Mon, Apr 22, 2024 at 3:44 PM Cui, Lili <lili.cui@intel.com> wrote:
> >>> On 22.04.2024 06:09, Hongtao Liu wrote:
> >>>> On Fri, Apr 19, 2024 at 5:29 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>
> >>>>> Since we uniformly permit D suffixes in Intel mode whenever in AT&T
> >>>>> mode an L suffix may be used, we need to be consistent with this.
> >>>> I think we need to forbid the D suffix for APX NDD SHL/SHR under Intel
> >>>> mode to avoid ambiguity.
> >>>
> >>> Hmm. Special casing just two insns is out of question imo (in fact that's what
> >>> is - unintentionally - partly happening prior to the change here).
> >>>
> > I know  the suffix L is needed in AT&T mode to specify the operand
> > size to avoid ambiguity.
> > But why do we need the suffix D for Intel mode?
>
> We don't need it. But that's not just here; the vast majority of insns should
> never have permitted suffixes in Intel syntax. Yet here we are. And the
> question is what to do about it. What I've been considering in the meantime
> is to disallow suffixes where not needed by default, but have a command line
> option to restore original behavior (perhaps right away with a deprecation
> warning), just to allow people to get their (bogus) code to build again (or,
> if need be, to work around issues we might introduce, i.e. mistakenly
> refusing use of a suffix where one might in fact be needed). Thoughts?
I prefer to issue a deprecation warning and drop the support in some
future release.
Easy maintenance.
>
> Jan



-- 
BR,
Hongtao