Prevent TYPE_PRECISION on VECTOR_TYPEs
Checks
Commit Message
The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
ICEs when tree checking is enabled. This should avoid wrong-code
in cases like PR110182 and instead ICE.
It also introduces a TYPE_PRECISION_RAW accessor and adjusts
places I found that are eligible to use that.
Bootstrapped and tested on x86_64-unknown-linux-gnu with all
languages enabled.
OK for trunk? There is definitely going to be fallout but it
should be straight-forward to fix with quick fixes using
TYPE_PRECISION_RAW possible.
Thanks,
Richard.
* tree.h (TYPE_PRECISION): Check for non-VECTOR_TYPE.
(TYPE_PRECISION_RAW): Provide raw access to the precision
field.
* tree.cc (verify_type_variant): Compare TYPE_PRECISION_RAW.
(gimple_canonical_types_compatible_p): Likewise.
* tree-streamer-out.cc (pack_ts_type_common_value_fields):
Stream TYPE_PRECISION_RAW.
* tree-streamer-in.cc (unpack_ts_type_common_value_fields):
Likewise.
* lto-streamer-out.cc (hash_tree): Hash TYPE_PRECISION_RAW.
gcc/lto/
* lto-common.cc (compare_tree_sccs_1): Use TYPE_PRECISION_RAW.
---
gcc/lto-streamer-out.cc | 2 +-
gcc/lto/lto-common.cc | 2 +-
gcc/tree-streamer-in.cc | 2 +-
gcc/tree-streamer-out.cc | 2 +-
gcc/tree.cc | 6 +++---
gcc/tree.h | 4 +++-
6 files changed, 10 insertions(+), 8 deletions(-)
Comments
On Tue, Jun 27, 2023 at 11:45:33AM +0200, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> It also introduces a TYPE_PRECISION_RAW accessor and adjusts
> places I found that are eligible to use that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu with all
> languages enabled.
>
> OK for trunk? There is definitely going to be fallout but it
> should be straight-forward to fix with quick fixes using
> TYPE_PRECISION_RAW possible.
>
> Thanks,
> Richard.
>
> * tree.h (TYPE_PRECISION): Check for non-VECTOR_TYPE.
> (TYPE_PRECISION_RAW): Provide raw access to the precision
> field.
> * tree.cc (verify_type_variant): Compare TYPE_PRECISION_RAW.
> (gimple_canonical_types_compatible_p): Likewise.
> * tree-streamer-out.cc (pack_ts_type_common_value_fields):
> Stream TYPE_PRECISION_RAW.
> * tree-streamer-in.cc (unpack_ts_type_common_value_fields):
> Likewise.
> * lto-streamer-out.cc (hash_tree): Hash TYPE_PRECISION_RAW.
>
> gcc/lto/
> * lto-common.cc (compare_tree_sccs_1): Use TYPE_PRECISION_RAW.
LGTM.
Jakub
It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you!
cd gcc && mkdir __BUILD__ && cd __BUILD__
../configure \
--target=riscv64-unknown-elf \
--prefix=<somewhere-to-install> \
--disable-shared \
--enable-threads \
--enable-tls \
--enable-languages=c,c++ \
--with-system-zlib \
--with-newlib \
--disable-libmudflap \
--disable-libssp \
--disable-libquadmath \
--disable-libgomp \
--enable-nls \
--disable-tm-clone-registry \
--enable-multilib \
--src=`pwd`/../ \
--with-abi=lp64d \
--with-arch=rv64imafdcv \
--with-tune=rocket \
--with-isa-spec=20191213 \
--enable-werror \
--enable-bootstrap \
CFLAGS_FOR_BUILD="-O0 -g" \
CXXFLAGS_FOR_BUILD="-O0 -g" \
CFLAGS_FOR_TARGET="-O0 -g" \
CXXFLAGS_FOR_TARGET="-O0 -g" \
BOOT_CFLAGS="-O0 -g" \
CFLAGS="-O0 -g" \
CXXFLAGS="-O0 -g" \
GM2FLAGS_FOR_TARGET="-O0 -g" \
GOCFLAGS_FOR_TARGET="-O0 -g" \
GDCFLAGS_FOR_TARGET="-O0 -g"
make -j $(nproc) all-gcc && make install-gcc
Then run one test file build like below, and you may see the ICE similar to below.
../__RISC-V_INSTALL_/bin/riscv64-unknown-elf-gcc -O2 --param riscv-autovec-preference=fixed-vlmax gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c
during GIMPLE pass: widening_mul
In file included from gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c:4:
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c: In function 'f3_init':
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c:249:1: internal compiler error: tree check: expected none of vector_type, have vector_type in divmod_candidate_p, at tree-ssa-math-opts.cc:4998
249 | f3_init (int8_t *__restrict x, int8_t *__restrict x2, int64_t *__restrict y,
| ^~~~~~~
0x1b1584e tree_not_check_failed(tree_node const*, char const*, int, char const*, ...)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.cc:8936
0xd74e9e tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.h:3581
0x196150c divmod_candidate_p
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:4998
0x196164f convert_to_divmod
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5041
0x196383d after_dom_children
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5580
0x299bcb4 dom_walker::walk(basic_block_def*)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/domwalk.cc:354
0x1963d09 execute
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5666
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.
Pan
-----Original Message-----
From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Jakub Jelinek via Gcc-patches
Sent: Tuesday, June 27, 2023 5:47 PM
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com
Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
On Tue, Jun 27, 2023 at 11:45:33AM +0200, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> It also introduces a TYPE_PRECISION_RAW accessor and adjusts
> places I found that are eligible to use that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu with all
> languages enabled.
>
> OK for trunk? There is definitely going to be fallout but it
> should be straight-forward to fix with quick fixes using
> TYPE_PRECISION_RAW possible.
>
> Thanks,
> Richard.
>
> * tree.h (TYPE_PRECISION): Check for non-VECTOR_TYPE.
> (TYPE_PRECISION_RAW): Provide raw access to the precision
> field.
> * tree.cc (verify_type_variant): Compare TYPE_PRECISION_RAW.
> (gimple_canonical_types_compatible_p): Likewise.
> * tree-streamer-out.cc (pack_ts_type_common_value_fields):
> Stream TYPE_PRECISION_RAW.
> * tree-streamer-in.cc (unpack_ts_type_common_value_fields):
> Likewise.
> * lto-streamer-out.cc (hash_tree): Hash TYPE_PRECISION_RAW.
>
> gcc/lto/
> * lto-common.cc (compare_tree_sccs_1): Use TYPE_PRECISION_RAW.
LGTM.
Jakub
Sorry for disturbing, cc kito, juzhe and robin for awareness.
Pan
-----Original Message-----
From: Li, Pan2
Sent: Thursday, June 29, 2023 12:05 PM
To: Jakub Jelinek <jakub@redhat.com>; Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com
Subject: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you!
cd gcc && mkdir __BUILD__ && cd __BUILD__
../configure \
--target=riscv64-unknown-elf \
--prefix=<somewhere-to-install> \
--disable-shared \
--enable-threads \
--enable-tls \
--enable-languages=c,c++ \
--with-system-zlib \
--with-newlib \
--disable-libmudflap \
--disable-libssp \
--disable-libquadmath \
--disable-libgomp \
--enable-nls \
--disable-tm-clone-registry \
--enable-multilib \
--src=`pwd`/../ \
--with-abi=lp64d \
--with-arch=rv64imafdcv \
--with-tune=rocket \
--with-isa-spec=20191213 \
--enable-werror \
--enable-bootstrap \
CFLAGS_FOR_BUILD="-O0 -g" \
CXXFLAGS_FOR_BUILD="-O0 -g" \
CFLAGS_FOR_TARGET="-O0 -g" \
CXXFLAGS_FOR_TARGET="-O0 -g" \
BOOT_CFLAGS="-O0 -g" \
CFLAGS="-O0 -g" \
CXXFLAGS="-O0 -g" \
GM2FLAGS_FOR_TARGET="-O0 -g" \
GOCFLAGS_FOR_TARGET="-O0 -g" \
GDCFLAGS_FOR_TARGET="-O0 -g"
make -j $(nproc) all-gcc && make install-gcc
Then run one test file build like below, and you may see the ICE similar to below.
../__RISC-V_INSTALL_/bin/riscv64-unknown-elf-gcc -O2 --param riscv-autovec-preference=fixed-vlmax gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c
during GIMPLE pass: widening_mul
In file included from gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c:4:
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c: In function 'f3_init':
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c:249:1: internal compiler error: tree check: expected none of vector_type, have vector_type in divmod_candidate_p, at tree-ssa-math-opts.cc:4998
249 | f3_init (int8_t *__restrict x, int8_t *__restrict x2, int64_t *__restrict y,
| ^~~~~~~
0x1b1584e tree_not_check_failed(tree_node const*, char const*, int, char const*, ...)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.cc:8936
0xd74e9e tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.h:3581
0x196150c divmod_candidate_p
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:4998
0x196164f convert_to_divmod
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5041
0x196383d after_dom_children
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5580
0x299bcb4 dom_walker::walk(basic_block_def*)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/domwalk.cc:354
0x1963d09 execute
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5666
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.
Pan
-----Original Message-----
From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Jakub Jelinek via Gcc-patches
Sent: Tuesday, June 27, 2023 5:47 PM
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com
Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
On Tue, Jun 27, 2023 at 11:45:33AM +0200, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> It also introduces a TYPE_PRECISION_RAW accessor and adjusts
> places I found that are eligible to use that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu with all
> languages enabled.
>
> OK for trunk? There is definitely going to be fallout but it
> should be straight-forward to fix with quick fixes using
> TYPE_PRECISION_RAW possible.
>
> Thanks,
> Richard.
>
> * tree.h (TYPE_PRECISION): Check for non-VECTOR_TYPE.
> (TYPE_PRECISION_RAW): Provide raw access to the precision
> field.
> * tree.cc (verify_type_variant): Compare TYPE_PRECISION_RAW.
> (gimple_canonical_types_compatible_p): Likewise.
> * tree-streamer-out.cc (pack_ts_type_common_value_fields):
> Stream TYPE_PRECISION_RAW.
> * tree-streamer-in.cc (unpack_ts_type_common_value_fields):
> Likewise.
> * lto-streamer-out.cc (hash_tree): Hash TYPE_PRECISION_RAW.
>
> gcc/lto/
> * lto-common.cc (compare_tree_sccs_1): Use TYPE_PRECISION_RAW.
LGTM.
Jakub
On 6/28/23 22:04, Li, Pan2 wrote:
> It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you!
I've one ICE due to this change as well but it wasn't in the
tree-ssa-math-opts.code like this one is. In my case we're in a place
where it doesn't look like we expect a vector type to show up, but it
does and we can likely just prune it away.
Anyway, your fault is in here:
divmod_candidate_p:
if (TYPE_PRECISION (type) <= HOST_BITS_PER_WIDE_INT
&& TYPE_PRECISION (type) <= BITS_PER_WORD)
return false;
TYPE is almost certainly a vector type. The question we need to answer
(and I'm not likely to get to it tomorrow) would be whether or not TYPE
can legitimately be a vector type here.
The whole point of Richi's change is to detect invalid uses of
TYPE_PRECISION. So it's not a big surprise that we're finding a few as
the change gets wider testing.
jeff
On Wed, 28 Jun 2023, Jeff Law wrote:
>
>
> On 6/28/23 22:04, Li, Pan2 wrote:
> > It seems this patch may result in many test ICE failures on RISC-V backend.
> > Could you help to double confirm about it follow the possible reproduce
> > steps like blow? Thank you!
> I've one ICE due to this change as well but it wasn't in the
> tree-ssa-math-opts.code like this one is. In my case we're in a place where
> it doesn't look like we expect a vector type to show up, but it does and we
> can likely just prune it away.
>
> Anyway, your fault is in here:
>
>
>
> divmod_candidate_p:
>
> if (TYPE_PRECISION (type) <= HOST_BITS_PER_WIDE_INT
> && TYPE_PRECISION (type) <= BITS_PER_WORD)
> return false;
>
> TYPE is almost certainly a vector type. The question we need to answer (and
> I'm not likely to get to it tomorrow) would be whether or not TYPE can
> legitimately be a vector type here.
I think GCN people wanted to make this code work for vectors, the
most obvious local fix is to use element_precision (type) above.
Note usually vector integer divisions are not a thing so this might
explain why you're seeing this only with RVV?
Richard.
> I think GCN people wanted to make this code work for vectors, the
> most obvious local fix is to use element_precision (type) above.
>
> Note usually vector integer divisions are not a thing so this might
> explain why you're seeing this only with RVV?
Since nobody else has provided a patch yet, is the attached OK as long
as x86 bootstrap and testsuite are clean?
Regards
Robin
From 5ac3bb96cae0af99cefeaa225806de67e268e8f5 Mon Sep 17 00:00:00 2001
From: Robin Dapp <rdapp@ventanamicro.com>
Date: Thu, 29 Jun 2023 11:35:02 +0200
Subject: [PATCH] ssa-math-opts: Use element_precision.
The recent TYPE_PRECISION changes to detect improper usage
cause an ICE in divmod_candidate_p for RVV when called with
a vector type. Therefore, use element_precision instead.
gcc/ChangeLog:
* tree-ssa-math-opts.cc (divmod_candidate_p): Use
element_precision.
---
gcc/tree-ssa-math-opts.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index da01d4ab2b6..701fce2ab61 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -4995,8 +4995,8 @@ divmod_candidate_p (gassign *stmt)
if (integer_pow2p (op2))
return false;
- if (TYPE_PRECISION (type) <= HOST_BITS_PER_WIDE_INT
- && TYPE_PRECISION (type) <= BITS_PER_WORD)
+ if (element_precision (type) <= HOST_BITS_PER_WIDE_INT
+ && element_precision (type) <= BITS_PER_WORD)
return false;
/* If the divisor is not power of 2 and the precision wider than
On Thu, 29 Jun 2023, Robin Dapp wrote:
> > I think GCN people wanted to make this code work for vectors, the
> > most obvious local fix is to use element_precision (type) above.
> >
> > Note usually vector integer divisions are not a thing so this might
> > explain why you're seeing this only with RVV?
>
> Since nobody else has provided a patch yet, is the attached OK as long
> as x86 bootstrap and testsuite are clean?
Yes.
Thanks,
Richard.
> Regards
> Robin
>
> From 5ac3bb96cae0af99cefeaa225806de67e268e8f5 Mon Sep 17 00:00:00 2001
> From: Robin Dapp <rdapp@ventanamicro.com>
> Date: Thu, 29 Jun 2023 11:35:02 +0200
> Subject: [PATCH] ssa-math-opts: Use element_precision.
>
> The recent TYPE_PRECISION changes to detect improper usage
> cause an ICE in divmod_candidate_p for RVV when called with
> a vector type. Therefore, use element_precision instead.
>
> gcc/ChangeLog:
>
> * tree-ssa-math-opts.cc (divmod_candidate_p): Use
> element_precision.
> ---
> gcc/tree-ssa-math-opts.cc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
> index da01d4ab2b6..701fce2ab61 100644
> --- a/gcc/tree-ssa-math-opts.cc
> +++ b/gcc/tree-ssa-math-opts.cc
> @@ -4995,8 +4995,8 @@ divmod_candidate_p (gassign *stmt)
> if (integer_pow2p (op2))
> return false;
>
> - if (TYPE_PRECISION (type) <= HOST_BITS_PER_WIDE_INT
> - && TYPE_PRECISION (type) <= BITS_PER_WORD)
> + if (element_precision (type) <= HOST_BITS_PER_WIDE_INT
> + && element_precision (type) <= BITS_PER_WORD)
> return false;
>
> /* If the divisor is not power of 2 and the precision wider than
>
Hi, Richi.
I tried to debug this ICE:
(gdb) call print_gimple_stmt(stdout,stmt,0,0)
vect_patt_2876.406_2862 = vect_patt_2877.405_2864 % { 6, ... };
(gdb) p type->type_common.mode
$2 = E_VNx4HImode
Currently, I have no ideal how to walk around this ICE in RISC-V port.
Do you have any suggestions?
Thanks.
juzhe.zhong@rivai.ai
From: Li, Pan2
Date: 2023-06-29 12:18
To: Jakub Jelinek; Richard Biener
CC: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com; kito.cheng@gmail.com; juzhe.zhong@rivai.ai; rdapp.gcc@gmail.com
Subject: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
Sorry for disturbing, cc kito, juzhe and robin for awareness.
Pan
-----Original Message-----
From: Li, Pan2
Sent: Thursday, June 29, 2023 12:05 PM
To: Jakub Jelinek <jakub@redhat.com>; Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com
Subject: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you!
cd gcc && mkdir __BUILD__ && cd __BUILD__
../configure \
--target=riscv64-unknown-elf \
--prefix=<somewhere-to-install> \
--disable-shared \
--enable-threads \
--enable-tls \
--enable-languages=c,c++ \
--with-system-zlib \
--with-newlib \
--disable-libmudflap \
--disable-libssp \
--disable-libquadmath \
--disable-libgomp \
--enable-nls \
--disable-tm-clone-registry \
--enable-multilib \
--src=`pwd`/../ \
--with-abi=lp64d \
--with-arch=rv64imafdcv \
--with-tune=rocket \
--with-isa-spec=20191213 \
--enable-werror \
--enable-bootstrap \
CFLAGS_FOR_BUILD="-O0 -g" \
CXXFLAGS_FOR_BUILD="-O0 -g" \
CFLAGS_FOR_TARGET="-O0 -g" \
CXXFLAGS_FOR_TARGET="-O0 -g" \
BOOT_CFLAGS="-O0 -g" \
CFLAGS="-O0 -g" \
CXXFLAGS="-O0 -g" \
GM2FLAGS_FOR_TARGET="-O0 -g" \
GOCFLAGS_FOR_TARGET="-O0 -g" \
GDCFLAGS_FOR_TARGET="-O0 -g"
make -j $(nproc) all-gcc && make install-gcc
Then run one test file build like below, and you may see the ICE similar to below.
../__RISC-V_INSTALL_/bin/riscv64-unknown-elf-gcc -O2 --param riscv-autovec-preference=fixed-vlmax gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c
during GIMPLE pass: widening_mul
In file included from gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c:4:
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c: In function 'f3_init':
gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c:249:1: internal compiler error: tree check: expected none of vector_type, have vector_type in divmod_candidate_p, at tree-ssa-math-opts.cc:4998
249 | f3_init (int8_t *__restrict x, int8_t *__restrict x2, int64_t *__restrict y,
| ^~~~~~~
0x1b1584e tree_not_check_failed(tree_node const*, char const*, int, char const*, ...)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.cc:8936
0xd74e9e tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree.h:3581
0x196150c divmod_candidate_p
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:4998
0x196164f convert_to_divmod
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5041
0x196383d after_dom_children
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5580
0x299bcb4 dom_walker::walk(basic_block_def*)
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/domwalk.cc:354
0x1963d09 execute
/home/pli/repos/gcc/444/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-ssa-math-opts.cc:5666
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.
Pan
-----Original Message-----
From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org> On Behalf Of Jakub Jelinek via Gcc-patches
Sent: Tuesday, June 27, 2023 5:47 PM
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org; jeffreyalaw@gmail.com
Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
On Tue, Jun 27, 2023 at 11:45:33AM +0200, Richard Biener wrote:
> The following makes sure that using TYPE_PRECISION on VECTOR_TYPE
> ICEs when tree checking is enabled. This should avoid wrong-code
> in cases like PR110182 and instead ICE.
>
> It also introduces a TYPE_PRECISION_RAW accessor and adjusts
> places I found that are eligible to use that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu with all
> languages enabled.
>
> OK for trunk? There is definitely going to be fallout but it
> should be straight-forward to fix with quick fixes using
> TYPE_PRECISION_RAW possible.
>
> Thanks,
> Richard.
>
> * tree.h (TYPE_PRECISION): Check for non-VECTOR_TYPE.
> (TYPE_PRECISION_RAW): Provide raw access to the precision
> field.
> * tree.cc (verify_type_variant): Compare TYPE_PRECISION_RAW.
> (gimple_canonical_types_compatible_p): Likewise.
> * tree-streamer-out.cc (pack_ts_type_common_value_fields):
> Stream TYPE_PRECISION_RAW.
> * tree-streamer-in.cc (unpack_ts_type_common_value_fields):
> Likewise.
> * lto-streamer-out.cc (hash_tree): Hash TYPE_PRECISION_RAW.
>
> gcc/lto/
> * lto-common.cc (compare_tree_sccs_1): Use TYPE_PRECISION_RAW.
LGTM.
Jakub
> Currently, I have no ideal how to walk around this ICE in RISC-V port.
> Do you have any suggestions?
I'm already bootstrapping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623184.html
I replied to all but it seems you got lost in the thread?
Regards
Robin
Ah, the one sub-thread continued before you were CC'ed.
Sorry about that.
Regards
Robin
Yes. Thanks for taking care of it!
juzhe.zhong@rivai.ai
From: Robin Dapp
Date: 2023-06-29 18:07
To: juzhe.zhong@rivai.ai; pan2.li; Richard Biener
CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng
Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
Ah, the one sub-thread continued before you were CC'ed.
Sorry about that.
Regards
Robin
>> Since nobody else has provided a patch yet, is the attached OK as long
>> as x86 bootstrap and testsuite are clean?
>
> Yes.
Bootstrap and testsuite are good. Going to commit.
Thanks.
Regards
Robin
On 6/29/23 02:11, Richard Biener wrote:
> On Wed, 28 Jun 2023, Jeff Law wrote:
>
>>
>>
>> On 6/28/23 22:04, Li, Pan2 wrote:
>>> It seems this patch may result in many test ICE failures on RISC-V backend.
>>> Could you help to double confirm about it follow the possible reproduce
>>> steps like blow? Thank you!
>> I've one ICE due to this change as well but it wasn't in the
>> tree-ssa-math-opts.code like this one is. In my case we're in a place where
>> it doesn't look like we expect a vector type to show up, but it does and we
>> can likely just prune it away.
>>
>> Anyway, your fault is in here:
>>
>>
>>
>> divmod_candidate_p:
>>
>> if (TYPE_PRECISION (type) <= HOST_BITS_PER_WIDE_INT
>> && TYPE_PRECISION (type) <= BITS_PER_WORD)
>> return false;
>>
>> TYPE is almost certainly a vector type. The question we need to answer (and
>> I'm not likely to get to it tomorrow) would be whether or not TYPE can
>> legitimately be a vector type here.
>
> I think GCN people wanted to make this code work for vectors, the
> most obvious local fix is to use element_precision (type) above.
>
> Note usually vector integer divisions are not a thing so this might
> explain why you're seeing this only with RVV?
Vector integer division is available in RVV, it's also available in
Tachyum's chip. So GCN isn't alone in wanting this capability.
jeff
@@ -1373,7 +1373,7 @@ hash_tree (struct streamer_tree_cache_d *cache, hash_map<tree, hashval_t> *map,
if (AGGREGATE_TYPE_P (t))
hstate.add_flag (TYPE_TYPELESS_STORAGE (t));
hstate.commit_flag ();
- hstate.add_int (TYPE_PRECISION (t));
+ hstate.add_int (TYPE_PRECISION_RAW (t));
hstate.add_int (TYPE_ALIGN (t));
hstate.add_int (TYPE_EMPTY_P (t));
}
@@ -1280,7 +1280,7 @@ compare_tree_sccs_1 (tree t1, tree t2, tree **map)
compare_values (TYPE_RESTRICT);
compare_values (TYPE_USER_ALIGN);
compare_values (TYPE_READONLY);
- compare_values (TYPE_PRECISION);
+ compare_values (TYPE_PRECISION_RAW);
compare_values (TYPE_ALIGN);
/* Do not compare TYPE_ALIAS_SET. Doing so introduce ordering issues
with calls to get_alias_set which may initialize it for streamed
@@ -387,7 +387,7 @@ unpack_ts_type_common_value_fields (struct bitpack_d *bp, tree expr)
TYPE_TYPELESS_STORAGE (expr) = (unsigned) bp_unpack_value (bp, 1);
TYPE_EMPTY_P (expr) = (unsigned) bp_unpack_value (bp, 1);
TYPE_NO_NAMED_ARGS_STDARG_P (expr) = (unsigned) bp_unpack_value (bp, 1);
- TYPE_PRECISION (expr) = bp_unpack_var_len_unsigned (bp);
+ TYPE_PRECISION_RAW (expr) = bp_unpack_var_len_unsigned (bp);
SET_TYPE_ALIGN (expr, bp_unpack_var_len_unsigned (bp));
#ifdef ACCEL_COMPILER
if (TYPE_ALIGN (expr) > targetm.absolute_biggest_alignment)
@@ -356,7 +356,7 @@ pack_ts_type_common_value_fields (struct bitpack_d *bp, tree expr)
bp_pack_value (bp, TYPE_TYPELESS_STORAGE (expr), 1);
bp_pack_value (bp, TYPE_EMPTY_P (expr), 1);
bp_pack_value (bp, TYPE_NO_NAMED_ARGS_STDARG_P (expr), 1);
- bp_pack_var_len_unsigned (bp, TYPE_PRECISION (expr));
+ bp_pack_var_len_unsigned (bp, TYPE_PRECISION_RAW (expr));
bp_pack_var_len_unsigned (bp, TYPE_ALIGN (expr));
}
@@ -13423,7 +13423,7 @@ verify_type_variant (const_tree t, tree tv)
}
verify_variant_match (TYPE_NEEDS_CONSTRUCTING);
}
- verify_variant_match (TYPE_PRECISION);
+ verify_variant_match (TYPE_PRECISION_RAW);
if (RECORD_OR_UNION_TYPE_P (t))
verify_variant_match (TYPE_TRANSPARENT_AGGR);
else if (TREE_CODE (t) == ARRAY_TYPE)
@@ -13701,8 +13701,8 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2,
|| TREE_CODE (t1) == OFFSET_TYPE
|| POINTER_TYPE_P (t1))
{
- /* Can't be the same type if they have different recision. */
- if (TYPE_PRECISION (t1) != TYPE_PRECISION (t2))
+ /* Can't be the same type if they have different precision. */
+ if (TYPE_PRECISION_RAW (t1) != TYPE_PRECISION_RAW (t2))
return false;
/* In some cases the signed and unsigned types are required to be
@@ -2191,7 +2191,9 @@ class auto_suppress_location_wrappers
#define TYPE_SIZE_UNIT(NODE) (TYPE_CHECK (NODE)->type_common.size_unit)
#define TYPE_POINTER_TO(NODE) (TYPE_CHECK (NODE)->type_common.pointer_to)
#define TYPE_REFERENCE_TO(NODE) (TYPE_CHECK (NODE)->type_common.reference_to)
-#define TYPE_PRECISION(NODE) (TYPE_CHECK (NODE)->type_common.precision)
+#define TYPE_PRECISION(NODE) \
+ (TREE_NOT_CHECK (TYPE_CHECK (NODE), VECTOR_TYPE)->type_common.precision)
+#define TYPE_PRECISION_RAW(NODE) (TYPE_CHECK (NODE)->type_common.precision)
#define TYPE_NAME(NODE) (TYPE_CHECK (NODE)->type_common.name)
#define TYPE_NEXT_VARIANT(NODE) (TYPE_CHECK (NODE)->type_common.next_variant)
#define TYPE_MAIN_VARIANT(NODE) (TYPE_CHECK (NODE)->type_common.main_variant)