[Bug target/111119] New: maskload and maskstore for integer modes are oddly conditional on AVX2

[Bug target/111119] New: maskload and maskstore for integer modes are oddly conditional on AVX2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

            Bug ID: 111119
           Summary: maskload and maskstore for integer modes are oddly
                    conditional on AVX2
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We have

(define_expand "maskload<mode><sseintvecmodelower>"
  [(set (match_operand:V48_AVX2 0 "register_operand")
    (unspec:V48_AVX2
      [(match_operand:<sseintvecmode> 2 "register_operand")
       (match_operand:V48_AVX2 1 "memory_operand")]
      UNSPEC_MASKMOV))]
  "TARGET_AVX")

and

(define_mode_iterator V48_AVX2
  [V4SF V2DF
   V8SF V4DF
   (V4SI "TARGET_AVX2") (V2DI "TARGET_AVX2")
   (V8SI "TARGET_AVX2") (V4DI "TARGET_AVX2")])

so for example maskloadv4siv4si is disabled with just -mavx while the actual
instruction can operate just fine on SImode sized data by pretending its
SFmode.

check_effective_target_vect_masked_load is conditional on AVX, not AVX2.

With just AVX we can still use SSE2 vectorization for integer operations using
masked loads/stores from AVX.

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
See https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577577.html for the
attempt to move x86 to the internal-fn representation

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Richard Biener from comment #0)
> We have
> 
> (define_expand "maskload<mode><sseintvecmodelower>"
>   [(set (match_operand:V48_AVX2 0 "register_operand")
>     (unspec:V48_AVX2
>       [(match_operand:<sseintvecmode> 2 "register_operand")
>        (match_operand:V48_AVX2 1 "memory_operand")]
>       UNSPEC_MASKMOV))]
>   "TARGET_AVX")
> 
> and
> 
> (define_mode_iterator V48_AVX2
>   [V4SF V2DF
>    V8SF V4DF
>    (V4SI "TARGET_AVX2") (V2DI "TARGET_AVX2")
>    (V8SI "TARGET_AVX2") (V4DI "TARGET_AVX2")])
> 
> so for example maskloadv4siv4si is disabled with just -mavx while the actual
> instruction can operate just fine on SImode sized data by pretending its
> SFmode.
> 
> check_effective_target_vect_masked_load is conditional on AVX, not AVX2.
> 
> With just AVX we can still use SSE2 vectorization for integer operations
> using
> masked loads/stores from AVX.

I see, we can add an alternative like "noavx2,avx2" to generate vmaskmovps/pd
when avx2 is not available for integer.

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---

> I see, we can add an alternative like "noavx2,avx2" to generate
> vmaskmovps/pd when avx2 is not available for integer.

It's better to change assmeble output as
27423  if (TARGET_AVX2)
27424    return "v<sseintprefix>maskmov<ssemodesuffix>\t{%1, %2, %0|%0, %2,
%1}";
27425  else
27426    return "vmaskmov<ssefltmodesuffix>\t{%1, %2, %0|%0, %2, %1}";

No need to add alternative.

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:945217845db7edb499d66ac56480ce569002b83e

commit r14-3509-g945217845db7edb499d66ac56480ce569002b83e
Author: liuhongt <hongtao.liu@intel.com>
Date:   Fri Aug 25 08:46:26 2023 +0800

    Use vmaskmov{ps,pd} for VI48_128_256 when TARGET_AVX2 is not available.

    vpmaskmov{d,q} is available for TARGET_AVX2, vmaskmov{ps,ps} is
    available for TARGET_AVX, w/o TARGET_AVX2, we can use vmaskmov{ps,pd}
    for VI48_128_256

    gcc/ChangeLog:

            PR target/111119
            * config/i386/sse.md (V48_AVX2): Rename to ..
            (V48_128_256): .. this.
            (ssefltmodesuffix): Extend to V4SF/V8SF/V2DF/V4DF.
            (<avx_avx2>_maskload<ssemodesuffix><avxsizesuffix>): Change
            V48_AVX2 to V48_128_256, also generate vmaskmov{ps,pd} for
            integral modes when TARGET_AVX2 is not available.
            (<avx_avx2>_maskstore<ssemodesuffix><avxsizesuffix>): Ditto.
            (maskload<mode><sseintvecmodelower>): Change V48_AVX2 to
            V48_128_256.
            (maskstore<mode><sseintvecmodelower>): Ditto.

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

--- Comment #5 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in GCC14.

[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111119

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |14.0
         Resolution|---                         |FIXED

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
.