[PATCH v2] x86: Disallow GOT memory as vector memory operand

[H.J. Lu]

On Fri, Feb 7, 2025 at 5:13 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 07.02.2025 07:32, Jan Beulich wrote:
> > On 07.02.2025 06:22, H.J. Lu wrote:
> >> On Thu, Feb 6, 2025 at 9:02 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>> On 06.02.2025 04:32, H.J. Lu wrote:
> >>>> GOT memory is 4-byte for i386 and 8-byte for x86-64.  Disallow GOT memory
> >>>> as vector memory operand for vector instructions which don't support 32-bit
> >>>> nor 64-bit memory.
> >>>>
> >>>> PR gas/32624
> >>>> * config/tc-i386.c (output_disp): Disallow GOT memory as vector
> >>>> memory operand.
> >>>> * testsuite/gas/i386/got.s: Add vcvtph2qq with GOT memory.
> >>>> * testsuite/gas/i386/x86-64-gotpcrel-2.s: Add vcvtph2qq and
> >>>> vcvtps2pd with GOT memory.
> >>>> * testsuite/gas/i386/got-no-relax.d: Updated.
> >>>> * testsuite/gas/i386/got.d: Likewise.
> >>>> * testsuite/gas/i386/x86-64-gotpcrel-2.d: Likewise.
> >>>> * testsuite/gas/i386/i386.exp: Run inval-got.
> >>>> * testsuite/gas/i386/inval-got.l: New file.
> >>>> * testsuite/gas/i386/inval-got.s: Likewise.
> >>>> * testsuite/gas/i386/x86-64-inval-got.l: Likewise.
> >>>> * testsuite/gas/i386/x86-64-inval-got.l: Likewise.
> >>>> * testsuite/gas/i386/x86-64.exp: Run x86-64-inval-got.
> >>>
> >>> Hmm, I'm further puzzled: On what basis would VCVTPS2DQ and VCVTPH2QQ be
> >>> okay to use with an operand in GOT?
> >>>
> >>> And then, if I'm reading the added logic right,
> >>>
> >>>         VADDPS foo@GOTPCREL(%rip), %zmm0, %zmm1
> >>>
> >>> would be permitted despite having a 512-bit memory operand, just because
> >>> it also permits embedded broadcast (which isn't in use here). Whereas
> >>
> >> Only for broadcast.
> >
> > Hmm, perhaps I'm reading the code change incorrectly then. By checking
> > the template rather than i.types[] (as I had asked you to do) I would
> > assume templates permitting for broadcast would allow all forms of their
> > insns through.
>
> Now that I've tried out your patch, behavior is exactly as predicted: Of
>
>         vaddps foo@GOTPCREL(%rip), %zmm0, %zmm1
>         vaddps foo@GOTPCREL(%rip){1to16}, %zmm0, %zmm1
>         vaddps foo@GOTPCREL(%rip), %ymm0, %ymm1
>
> only the last one triggers the new error.
>
> Jan

Fixed in the v3 patch.

-- 
H.J.