[Bug tree-optimization/105668] New: [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre

[Bug tree-optimization/105668] New: [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre

[zsojka at seznam dot cz]

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

            Bug ID: 105668
           Summary: [13 Regression] ICE: in gimple_expand_vec_cond_expr,
                    at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

Created attachment 53004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53004&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -ftracer -fno-tree-fre testcase.c
during GIMPLE pass: isel
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:281
    6 | foo (_Complex float f)
      | ^~~
0x7f158f gimple_expand_vec_cond_expr
        /repo/gcc-trunk/gcc/gimple-isel.cc:281
0x7f158f gimple_expand_vec_exprs
        /repo/gcc-trunk/gcc/gimple-isel.cc:311
0x7f158f execute
        /repo/gcc-trunk/gcc/gimple-isel.cc:365
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-673-20220519175438-gd863ba23fb1-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-673-20220519175438-gd863ba23fb1-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220519 (experimental) (GCC)

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-05-20
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |13.0

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

    type <vector_type 0x7ffff6679540
        type <boolean_type 0x7ffff6679498 public TI

and there's no vcond_mask with V1TImode data and V1TImode mask.  veclower
doesn't touch the VEC_COND_EXPR but then it changes later so the condition is
defined
by a PHI node and no longer by a comparison.  As fallback we could try ISEL
to mask != 0 ? .. : .. which would probably solve this particular issue.

In the end it's also the target lacking symmetry in the provided patterns,
seemingly handling V1TImode only "half-way".

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |sayle at gcc dot gnu.org
            Summary|[13 Regression] ICE: in     |[13 Regression] ICE: in
                   |gimple_expand_vec_cond_expr |gimple_expand_vec_cond_expr
                   |, at gimple-isel.cc:281     |, at gimple-isel.cc:281
                   |with -O -ftracer            |with -O -ftracer
                   |-fno-tree-fre               |-fno-tree-fre since
                   |                            |r13-458-gd75d4293dcc029a7
           Keywords|needs-bisection             |

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-458-gd75d4293dcc029a7.

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot com

--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
I suspect that the middle-end could be a bit more forgiving whilst expanding
vcond_mask.  If a target doesn't provide V1TImode, GCC can fall back to using
V2DImode, and if that isn't supported V4SImode, then V8HImode then V16QImode.
On x86-64, these all use the same vblendvb instruction or pand,pandn,por logic
(also known as V128BImode :-).

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 20 May 2022, roger at nextmovesoftware dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105668
> 
> Roger Sayle <roger at nextmovesoftware dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |roger at nextmovesoftware dot com
> 
> --- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
> I suspect that the middle-end could be a bit more forgiving whilst expanding
> vcond_mask.  If a target doesn't provide V1TImode, GCC can fall back to using
> V2DImode, and if that isn't supported V4SImode, then V8HImode then V16QImode.
> On x86-64, these all use the same vblendvb instruction or pand,pandn,por logic
> (also known as V128BImode :-).

That assumes that selecting V4SImode is the same as selecting 
from V2DImode, that is, vcond works on the "bitlevel" and V4SI and V2DI
"naturally overlap" in a vector register (and they can be aliased).
I'm not sure that's something we generally assume in GCC.  IIRC with
RISC-V for example that would not be the case since they represent
vectors in a way to have V4{QI,HI,SI} with zero-extended lanes.

I'm not sure how RISC-V represents this to the middle-end and how
the middle-end could distinguish those cases.  (looks like none
of it is on trunk?)

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com

--- Comment #5 from Roger Sayle <roger at nextmovesoftware dot com> ---
Patches proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595382.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595383.html

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|roger at nextmovesoftware dot com  |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:793f847ba7dbe7638f1c27178868edbefd3a8108

commit r13-739-g793f847ba7dbe7638f1c27178868edbefd3a8108
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Tue May 24 15:15:12 2022 +0100

    PR tree-optimization/105668: Provide vcond_mask_v1tiv1ti pattern.

    This patch is an alternate/supplementary fix to PR tree-optimization/105668
    that provides a vcond_mask_v1titi optab/define_expand to the i386 backend.
    An undocumented feature/bug of GCC's vectorization is that any target that
    provides a vec_cmpeq<mode><mode> has to also provide a matching
    vcond_mask<mode><mode>.  This backend patch preserves the status quo,
    rather than fixes the underlying problem.

    One aspect of this clean-up is that ix86_expand_sse_movcc provides
    fallback implementations using pand/pandn/por that effectively make
    V2DImode and V1TImode vcond_mask available on any TARGET_SSE2, not
    just TARGET_SSE4_2.  This allows a simplification as V2DI mode can
    be handled by using a VI_128 mode iterator instead of a VI124_128
    mode iterator, and instead this define_expand is effectively renamed
    to provide a V1TImode vcond_mask expander (as V1TI isn't in VI_128).

    2022-05-24  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR tree-optimization/105668
            * config/i386/i386-expand.cc (ix86_expand_sse_movcc): Support
            V1TImode, just like V2DImode.
            * config/i386/sse.md (vcond_mask_<mode><sseintvecmodelower>):
            Use VI_128 mode iterator instead of VI124_128 to include V2DI.
            (vcond_mask_v2div2di): Delete.
            (vcond_mask_v1tiv1ti): New define_expand.

    gcc/testsuite/ChangeLog
            PR tree-optimization/105668
            * gcc.target/i386/pr105668.c: New test case.

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks to be fixed.

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Yes, it is.