public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
@ 2023-11-30 3:10 patrick at rivosinc dot com
2023-11-30 8:46 ` [Bug target/112773] " rguenth at gcc dot gnu.org
` (17 more replies)
0 siblings, 18 replies; 19+ messages in thread
From: patrick at rivosinc dot com @ 2023-11-30 3:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Bug ID: 112773
Summary: [14 Regression] RISC-V ICE: in
force_align_down_and_div, at poly-int.h:1828 on
rv32gcv_zvl256b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Created attachment 56724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56724&action=edit
-freport-bug output
during RTL pass: expand
red.c: In function 'e':
red.c:4:6: internal compiler error: in force_align_down_and_div, at
poly-int.h:1828
4 | void e(unsigned f) {
| ^
0x9b006c poly_int<2u, unsigned long> force_align_down_and_div<2u, unsigned
long, int>(poly_int<2u, unsigned long> const&, int)
../../../gcc/gcc/poly-int.h:1828
0x9b006c poly_int<2u, unsigned long> force_align_down_and_div<2u, unsigned
long, int>(poly_int<2u, unsigned long> const&, int)
../../../gcc/gcc/poly-int.h:1826
0x9b006c extract_bit_field_1
../../../gcc/gcc/expmed.cc:1861
0xe42532 extract_bit_field(rtx_def*, poly_int<2u, unsigned long>, poly_int<2u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
../../../gcc/gcc/expmed.cc:2149
0xe607a9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:11804
0xe6dddf expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../../gcc/gcc/expr.cc:9046
0xe6dddf expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../../gcc/gcc/expr.h:310
0xe6dddf store_expr(tree_node*, rtx_def*, int, bool, bool)
../../../gcc/gcc/expr.cc:6232
0xe6e679 expand_assignment(tree_node*, tree_node*, bool)
../../../gcc/gcc/expr.cc:6070
0xd29577 expand_gimple_stmt_1
../../../gcc/gcc/cfgexpand.cc:3947
0xd29577 expand_gimple_stmt
../../../gcc/gcc/cfgexpand.cc:4045
0xd2e6c0 expand_gimple_basic_block
../../../gcc/gcc/cfgexpand.cc:6101
0xd30656 execute
../../../gcc/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Preprocessed source stored into /scratch/tmp/ccSDQZzq.out file, please attach
this to your bugreport.
Reduced testcase:
long long a;
int b, c;
int *d;
void e(unsigned f) {
for (;; ++c)
if (f) {
a = 0;
for (; a <= 3; a++) {
f = 0;
for (; f <= 0; f++)
if ((long)a)
break;
}
if (b)
*d = f;
}
}
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
@ 2023-11-30 8:46 ` rguenth at gcc dot gnu.org
2023-11-30 9:06 ` juzhe.zhong at rivai dot ai
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-30 8:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
2023-11-30 8:46 ` [Bug target/112773] " rguenth at gcc dot gnu.org
@ 2023-11-30 9:06 ` juzhe.zhong at rivai dot ai
2023-11-30 17:10 ` patrick at rivosinc dot com
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-11-30 9:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
JuzheZhong <juzhe.zhong at rivai dot ai> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |juzhe.zhong at rivai dot ai
--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I don't have such issue with.
You need to try trunk GCC.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
2023-11-30 8:46 ` [Bug target/112773] " rguenth at gcc dot gnu.org
2023-11-30 9:06 ` juzhe.zhong at rivai dot ai
@ 2023-11-30 17:10 ` patrick at rivosinc dot com
2023-12-01 1:57 ` juzhe.zhong at rivai dot ai
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: patrick at rivosinc dot com @ 2023-11-30 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Patrick O'Neill <patrick at rivosinc dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #56724|0 |1
is obsolete| |
--- Comment #2 from Patrick O'Neill <patrick at rivosinc dot com> ---
Created attachment 56734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56734&action=edit
-freport-bug output
I'm still seeing this on the most recent trunk: r14-6020-g18d8a50a042
> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv32gcv_zvl256b -mabi=ilp32d -O3 -S red.c
during RTL pass: expand
red.c: In function 'e':
red.c:4:6: internal compiler error: in force_align_down_and_div, at
poly-int.h:1828
4 | void e(unsigned f) {
... (trimmed)
I've updated the -freport-bug-output with the most recent run.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (2 preceding siblings ...)
2023-11-30 17:10 ` patrick at rivosinc dot com
@ 2023-12-01 1:57 ` juzhe.zhong at rivai dot ai
2023-12-01 2:01 ` juzhe.zhong at rivai dot ai
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-12-01 1:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I see. I didn't reproduce the ICE since I didn't enable gcc_assert_checking.
Could you tell me how to enable it ?
I hack the codes as follows:
diff --git a/gcc/poly-int.h b/gcc/poly-int.h
index 828714ee910..24cce294414 100644
--- a/gcc/poly-int.h
+++ b/gcc/poly-int.h
@@ -1825,7 +1825,7 @@ template<unsigned int N, typename Ca, typename Cb>
inline poly_int<N, Ca>
force_align_down_and_div (const poly_int<N, Ca> &value, Cb align)
{
- gcc_checking_assert (can_align_p (value, align));
+ gcc_assert (can_align_p (value, align));
poly_int<N, Ca> r;
POLY_SET_COEFF (Ca, r, 0, ((value.coeffs[0]
Then I can see the assertion FAIL.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (3 preceding siblings ...)
2023-12-01 1:57 ` juzhe.zhong at rivai dot ai
@ 2023-12-01 2:01 ` juzhe.zhong at rivai dot ai
2023-12-01 2:02 ` juzhe.zhong at rivai dot ai
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-12-01 2:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #4 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
After reproducing the ICE.
I confirm the root cause is because we enable vec_extract for mask:
;; -------------------------------------------------------------------------
;; This extracts a bit (via QImode) from a bitmask vector.
;; -------------------------------------------------------------------------
(define_expand "vec_extract<mode>qi"
[(set (match_operand:QI 0 "register_operand")
(vec_select:QI
(match_operand:VB 1 "register_operand")
(parallel
[(match_operand 2 "nonmemory_operand")])))]
The ICE happens optimized IR is as follows:
_68 = BIT_FIELD_REF <mask__25.17_66, 1, POLY_INT_CST [3, 4]>;
can_align_p return false for POLY_INT_CST [3, 4] since the alignment require
multipe of 8:
force_align_down_and_div (X, BITS_PER_UNIT) -> BITS_PER_UNIT = 8.
It's ovbious POLY_INT_CST [3, 4] is definitely not aligned with 8.
I have no idea how to fix it.
CCing Robin who enable mask bit extraction should know much better than me.
And CCing Richard B and Richard S may give us some useful suggestions.
Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (4 preceding siblings ...)
2023-12-01 2:01 ` juzhe.zhong at rivai dot ai
@ 2023-12-01 2:02 ` juzhe.zhong at rivai dot ai
2023-12-01 2:05 ` patrick at rivosinc dot com
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-12-01 2:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Besides, the mask type is:
vector([4,4]) <signed-boolean:1>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (5 preceding siblings ...)
2023-12-01 2:02 ` juzhe.zhong at rivai dot ai
@ 2023-12-01 2:05 ` patrick at rivosinc dot com
2023-12-01 2:05 ` juzhe.zhong at rivai dot ai
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: patrick at rivosinc dot com @ 2023-12-01 2:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #6 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to JuzheZhong from comment #3)
> I see. I didn't reproduce the ICE since I didn't enable gcc_assert_checking.
>
> Could you tell me how to enable it ?
I didn't explicitly enable checking. The full configure command I ran with
(from -freport-bug output) is:
/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv
--with-sysroot=/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/sysroot
--with-pkgversion=g18d8a50a042 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2 -mcmodel=medlow'
I built the toolchain using riscv-gnu-toolchain `make linux`.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (6 preceding siblings ...)
2023-12-01 2:05 ` patrick at rivosinc dot com
@ 2023-12-01 2:05 ` juzhe.zhong at rivai dot ai
2023-12-01 10:27 ` rdapp at gcc dot gnu.org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-12-01 2:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Here is the compiler explorer for reference and easily see the issue:
https://godbolt.org/z/8v1dsKG3f
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (7 preceding siblings ...)
2023-12-01 2:05 ` juzhe.zhong at rivai dot ai
@ 2023-12-01 10:27 ` rdapp at gcc dot gnu.org
2023-12-01 11:54 ` rdapp at gcc dot gnu.org
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-12-01 10:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #8 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Thanks for the testcase. It looks pretty similar to the situation why I
introduced the bitmask extract in the first place and I don't think that's the
root cause.
As last time the problem is that the generic bit_field_ref expansion code does
not handle bitmask extraction with a precision < 8 very well and this is why we
run into an assertion failure. I worked around this by providing the extract
expander so we don't go down that road.
The difference to before is that the bit_field_ref occurs in the epilogue (i.e.
not LOOP_VINFO_FULLY_WITH_LENGTH_P) so we fall back.
Maybe we can work around it by providing a fold_extract_last implementation for
masks (even though the operation itself seems a bit weird). Will see how far I
get with it.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (8 preceding siblings ...)
2023-12-01 10:27 ` rdapp at gcc dot gnu.org
@ 2023-12-01 11:54 ` rdapp at gcc dot gnu.org
2023-12-01 12:07 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-12-01 11:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #9 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Ok, it's not the fold_extract_last expander. It just appeared that way here
because I disabled some other things.
What we want to do is extract the last element from a vector. This works as
long as we have a loop length (or a loop mask) as we can defer that to
vec_extract with element index len - 1.
In the epilog here we don't have either so the only workaround I can quickly
think of is allowing a poly_int constant as vec_extract index (where we know
the vector length and can extract the proper thing with a bit of extra work).
Richi, Richard: Is that somehow viable or am I on the wrong track?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (9 preceding siblings ...)
2023-12-01 11:54 ` rdapp at gcc dot gnu.org
@ 2023-12-01 12:07 ` rguenth at gcc dot gnu.org
2023-12-01 12:44 ` rdapp at gcc dot gnu.org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-01 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-12-01
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue might be we do not use vec_extract for memory arguments:
/* Use vec_extract patterns for extracting parts of vectors whenever
available. If that fails, see whether the current modes and bitregion
give a natural subreg. */
machine_mode outermode = GET_MODE (op0);
if (VECTOR_MODE_P (outermode) && !MEM_P (op0))
{
and somehow the original reg operand got spilled inbetween. That happens
here, after we could make vec_extract work for this.
/* Make sure we are playing with integral modes. Pun with subregs
if we aren't. */
opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
scalar_int_mode imode;
if (!op0_mode.exists (&imode) || imode != GET_MODE (op0))
{
...
else
{
poly_int64 size = GET_MODE_SIZE (GET_MODE (op0));
rtx mem = assign_stack_temp (GET_MODE (op0), size);
emit_move_insn (mem, op0);
op0 = adjust_bitfield_address_size (mem, BLKmode, 0, size);
}
now, if we spilled we can elide the round-down I think (which is for
the fear of accessing invalid memory). Thus like the following?
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index b294eabb08d..e2b38b87bdf 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -1856,7 +1856,7 @@ extract_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
/* If we have a memory source and a non-constant bit offset, restrict
the memory to the referenced bytes. This is a worst-case fallback
but is useful for things like vector booleans. */
- if (MEM_P (op0) && !bitnum.is_constant ())
+ if (MEM_P (str_rtx) && !bitnum.is_constant ())
{
bytenum = bits_to_bytes_round_down (bitnum);
bitnum = num_trailing_bits (bitnum);
but that defers the ICE to
during RTL pass: expand
t.c: In function 'e':
t.c:4:6: internal compiler error: in to_constant, at poly-int.h:588
4 | void e(unsigned f) {
| ^
0x10ea530 poly_int<2u, unsigned long>::to_constant() const
/home/rguenther/src/trunk/gcc/poly-int.h:588
0x13cec67 extract_bit_field_1
/home/rguenther/src/trunk/gcc/expmed.cc:1872
so I guess we really need to match the vec_extract pattern.
So you need to debug why that doesn't match here.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (10 preceding siblings ...)
2023-12-01 12:07 ` rguenth at gcc dot gnu.org
@ 2023-12-01 12:44 ` rdapp at gcc dot gnu.org
2023-12-01 13:20 ` rguenther at suse dot de
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-12-01 12:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> ---
When I define a vec_extract...bi pattern we don't enter the if (vec_extract) in
expmed because e.g.
bitsize = {1, 0}
bitnum = {3, 4}
and GET_MODE_BITSIZE (innermode) = {1, 0} with innermode = BImode.
This fails multiple_p (bitnum, GET_MODE_BITSIZE (innermode), &pos).
It is a multiple of course, but still dependent on the actual vector length.
(So we would also need to extract a [3 4] from the vector).
That would be the same as an extract_last with a CONST_M1 mask. Maybe that's
an option? So if we have an extract_last and no loop len or mask fall back to
an extract_last with a full mask? That would delegate the length calculation
to the backend.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (11 preceding siblings ...)
2023-12-01 12:44 ` rdapp at gcc dot gnu.org
@ 2023-12-01 13:20 ` rguenther at suse dot de
2023-12-01 21:16 ` rdapp at gcc dot gnu.org
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenther at suse dot de @ 2023-12-01 13:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 1 Dec 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
>
> --- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> When I define a vec_extract...bi pattern we don't enter the if (vec_extract) in
> expmed because e.g.
>
> bitsize = {1, 0}
> bitnum = {3, 4}
>
> and GET_MODE_BITSIZE (innermode) = {1, 0} with innermode = BImode.
>
> This fails multiple_p (bitnum, GET_MODE_BITSIZE (innermode), &pos).
>
> It is a multiple of course, but still dependent on the actual vector length.
> (So we would also need to extract a [3 4] from the vector).
>
> That would be the same as an extract_last with a CONST_M1 mask. Maybe that's
> an option? So if we have an extract_last and no loop len or mask fall back to
> an extract_last with a full mask? That would delegate the length calculation
> to the backend.
Hm, yeah, but is that an issue? I guess all vec_extract can end up
at a variable position with VLA?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (12 preceding siblings ...)
2023-12-01 13:20 ` rguenther at suse dot de
@ 2023-12-01 21:16 ` rdapp at gcc dot gnu.org
2023-12-14 16:54 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-12-01 21:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #13 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Mostly an issue because our expander is definitely not prepared to handle that
:)
It looks like aarch64's is, though, and ours can/should be changed then.
aarch64 doesn't need to implement a qi/bi extract from a mask because the
bit_field_ref fallback code works for sve masks.
There is (at least) three things that prevent us from creating a vec_extract
here. First, my old friend MODE_BITSIZE vs MODE_PRECISION, second we expect a
mask -> BI extract here (while we do mask -> QI extraction on the other path)
but I haven't yet defined a vec_extract...bi either.
Once those two are our of the way I still hit QI vs BI inconsistencies but I
think they can be sorted out. Then we emit a VLA vec_extract.
I hope to have a patch ready by Monday.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (13 preceding siblings ...)
2023-12-01 21:16 ` rdapp at gcc dot gnu.org
@ 2023-12-14 16:54 ` cvs-commit at gcc dot gnu.org
2023-12-14 19:51 ` patrick at rivosinc dot com
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-14 16:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:
https://gcc.gnu.org/g:0a5170b5f596bb5fcedf25d93952b979d02d1f56
commit r14-6555-g0a5170b5f596bb5fcedf25d93952b979d02d1f56
Author: Robin Dapp <rdapp@ventanamicro.com>
Date: Sun Dec 3 21:55:16 2023 +0100
expmed: Use GET_MODE_PRECISION and expander's output mode.
This changes the vec_extract path of extract_bit_field to use
GET_MODE_PRECISION instead of GET_MODE_BITSIZE and uses
the mode obtained from insn_data[icode].operand[0] as target mode.
Also, it adds a vec_extract<mode>bi expander for riscv that maps
to vec_extract<mode>qi. This fixes an ICE on riscv where we did
not find a vec_extract optab and continued with the generic code
which requires 1-byte alignment that riscv mask modes do not provide.
Apart from that it adds poly_int support to riscv's vec_extract
expander and makes the RVV..BImode -> QImode expander call
emit_vec_extract in order not to duplicate code.
gcc/ChangeLog:
PR target/112773
* config/riscv/autovec.md (vec_extract<mode>bi): New expander
calling vec_extract<mode>qi.
* config/riscv/riscv-protos.h (riscv_legitimize_poly_move):
Export.
(emit_vec_extract): Change argument from poly_int64 to rtx.
* config/riscv/riscv-v.cc (shuffle_extract_and_slide1up_patterns):
Ditto.
* config/riscv/riscv.cc (riscv_legitimize_poly_move): Export.
(riscv_legitimize_move): Use rtx instead of poly_int64.
* expmed.cc (store_bit_field_1): Change BITSIZE to PRECISION.
(extract_bit_field_1): Change BITSIZE to PRECISION and use
return mode from insn_data as target mode.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/pr112773.c: New test.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (14 preceding siblings ...)
2023-12-14 16:54 ` cvs-commit at gcc dot gnu.org
@ 2023-12-14 19:51 ` patrick at rivosinc dot com
2023-12-14 20:13 ` rdapp at gcc dot gnu.org
2023-12-14 21:09 ` patrick at rivosinc dot com
17 siblings, 0 replies; 19+ messages in thread
From: patrick at rivosinc dot com @ 2023-12-14 19:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Patrick O'Neill <patrick at rivosinc dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #15 from Patrick O'Neill <patrick at rivosinc dot com> ---
Fixed on trunk.
Weirdly this was fixed before Robin's patch by this patch:
r14-6472-g8501edba91e
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (15 preceding siblings ...)
2023-12-14 19:51 ` patrick at rivosinc dot com
@ 2023-12-14 20:13 ` rdapp at gcc dot gnu.org
2023-12-14 21:09 ` patrick at rivosinc dot com
17 siblings, 0 replies; 19+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-12-14 20:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #16 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I'd hope it was not fixed by this but just latent because we chose a VLS-mode
vectorization instead. Hopefully we're better off with the fix than without :)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
` (16 preceding siblings ...)
2023-12-14 20:13 ` rdapp at gcc dot gnu.org
@ 2023-12-14 21:09 ` patrick at rivosinc dot com
17 siblings, 0 replies; 19+ messages in thread
From: patrick at rivosinc dot com @ 2023-12-14 21:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #17 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Robin Dapp from comment #16)
> I'd hope it was not fixed by this but just latent because we chose a
> VLS-mode vectorization instead. Hopefully we're better off with the fix
> than without :)
Using -fno-vect-cost-model confirms that r14-6472-g8501edba91e didn't actually
fix the problem, but it's fixed on trunk. I'll send a patch to add
-fno-vect-cost-model to the testcase options.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-12-14 21:09 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-30 3:10 [Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b patrick at rivosinc dot com
2023-11-30 8:46 ` [Bug target/112773] " rguenth at gcc dot gnu.org
2023-11-30 9:06 ` juzhe.zhong at rivai dot ai
2023-11-30 17:10 ` patrick at rivosinc dot com
2023-12-01 1:57 ` juzhe.zhong at rivai dot ai
2023-12-01 2:01 ` juzhe.zhong at rivai dot ai
2023-12-01 2:02 ` juzhe.zhong at rivai dot ai
2023-12-01 2:05 ` patrick at rivosinc dot com
2023-12-01 2:05 ` juzhe.zhong at rivai dot ai
2023-12-01 10:27 ` rdapp at gcc dot gnu.org
2023-12-01 11:54 ` rdapp at gcc dot gnu.org
2023-12-01 12:07 ` rguenth at gcc dot gnu.org
2023-12-01 12:44 ` rdapp at gcc dot gnu.org
2023-12-01 13:20 ` rguenther at suse dot de
2023-12-01 21:16 ` rdapp at gcc dot gnu.org
2023-12-14 16:54 ` cvs-commit at gcc dot gnu.org
2023-12-14 19:51 ` patrick at rivosinc dot com
2023-12-14 20:13 ` rdapp at gcc dot gnu.org
2023-12-14 21:09 ` patrick at rivosinc dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).