This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 9/9] x86: correct VFPCLASSP{S,D} operand size handling


On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 29.10.2019 20:16, H.J. Lu wrote:
> > On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> With AVX512VL disabled (e.g. when writing code for the Knights family
> >> of processors) these insns aren't ambiguous when used with a memory
> >> source, and hence should be accepted without suffix or operand size
> >> specifier. When AVX512VL is enabled, to be consistent with this as
> >> well as other ambiguous operand size handling it seems better to just
> >> wanrn about the ambiguity in AT&T mode, and still default to 512-bit
> >> operands (on the assumption that the code may have been written without
> >> AVX512VL in mind yet).
> >
> > There is no need for this.   Memory size or suffix is always needed for them.
>
> It is not - what you say (again) is your private opinion, not (afaict)
> something based on some objective criteria. If I'm missing something
> here, please clarify, but recall that we've been discussing this before.
>

As I remembered, I didn't believe they should be treated differently,
depending on AVX512VL.  One should be able to tell what the operand
size is without checking if AVX512VL was disabled or not when the assembly
file was assembled.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]