Created attachment 53004 [details] 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)
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".
Started with r13-458-gd75d4293dcc029a7.
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 :-).
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?)
Patches proposed: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595382.html https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595383.html
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.
Looks to be fixed.
Yes, it is.