* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
@ 2023-10-10 3:35 ` pinskia at gcc dot gnu.org
2023-10-10 3:35 ` pinskia at gcc dot gnu.org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 3:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
AARCH64 did vectorize the code just using non-SVE which then allowed to be
optimized too.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
2023-10-10 3:35 ` [Bug tree-optimization/111751] " pinskia at gcc dot gnu.org
@ 2023-10-10 3:35 ` pinskia at gcc dot gnu.org
2023-10-10 3:36 ` pinskia at gcc dot gnu.org
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 3:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-10-10
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
2023-10-10 3:35 ` [Bug tree-optimization/111751] " pinskia at gcc dot gnu.org
2023-10-10 3:35 ` pinskia at gcc dot gnu.org
@ 2023-10-10 3:36 ` pinskia at gcc dot gnu.org
2023-10-10 3:41 ` pinskia at gcc dot gnu.org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 3:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If you add `-fno-vect-cost-model` to aarch64 compiling, then it uses SVE and
does not optimize to just `return 0`.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (2 preceding siblings ...)
2023-10-10 3:36 ` pinskia at gcc dot gnu.org
@ 2023-10-10 3:41 ` pinskia at gcc dot gnu.org
2023-10-10 3:51 ` juzhe.zhong at rivai dot ai
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 3:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... });
vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...
});
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (3 preceding siblings ...)
2023-10-10 3:41 ` pinskia at gcc dot gnu.org
@ 2023-10-10 3:51 ` juzhe.zhong at rivai dot ai
2023-10-10 3:55 ` pinskia at gcc dot gnu.org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 3:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Andrew Pinski from comment #4)
> The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
>
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
> vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
I don't ARM SVE has issues ...
If we can choose fixed length vector mode to vectorize it, it will be well
optimized.
I think this is RISC-V target dependent issue.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (4 preceding siblings ...)
2023-10-10 3:51 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 3:55 ` pinskia at gcc dot gnu.org
2023-10-10 4:00 ` juzhe.zhong at rivai dot ai
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-10-10 3:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> >
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
> > vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
>
> I don't ARM SVE has issues ...
It does as I mentioned if you use -fno-vect-cost-model, you get the above issue
which should be optimized really to a constant vector ...
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (5 preceding siblings ...)
2023-10-10 3:55 ` pinskia at gcc dot gnu.org
@ 2023-10-10 4:00 ` juzhe.zhong at rivai dot ai
2023-10-10 9:09 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 4:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to JuzheZhong from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> > >
> > > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > > vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > ... });
> > > vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > ... });
> >
> > I don't ARM SVE has issues ...
>
> It does as I mentioned if you use -fno-vect-cost-model, you get the above
> issue which should be optimized really to a constant vector ...
After investigation:
I found it failed to recognize its CONST_VECTOR value in FRE
/* Visit a load from a reference operator RHS, part of STMT, value number it,
and return true if the value number of the LHS has changed as a result. */
static bool
visit_reference_op_load (tree lhs, tree op, gimple *stmt)
{
bool changed = false;
tree result;
vn_reference_t res;
tree vuse = gimple_vuse (stmt);
tree last_vuse = vuse;
result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res, true,
&last_vuse);
/* We handle type-punning through unions by value-numbering based
on offset and size of the access. Be prepared to handle a
type-mismatch here via creating a VIEW_CONVERT_EXPR. */
if (result
&& !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE (op)))
{
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)))))
result = NULL_TREE;
....
The result is BLKmode, op is V16QImode
Then reach
/* Avoid the type punning in case the result mode has padding where
the op we lookup has not. */
if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)))))
result = NULL_TREE;
If I delete this code, RVV can optimize it.
Do you have any suggestion ?
This is my observation:
Breakpoint 6, visit_reference_op_load (lhs=0x7ffff68364c8, op=0x7ffff6874410,
stmt=0x7ffff6872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res,
true, &last_vuse);
(gdb) c
Continuing.
Breakpoint 6, visit_reference_op_load (lhs=0x7ffff68364c8, op=0x7ffff6874410,
stmt=0x7ffff6872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740 result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res,
true, &last_vuse);
(gdb) n
5746 && !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE
(op)))
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
$9 = void
(gdb) p op->typed.type->type_common.mode
$10 = E_V16QImode
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (6 preceding siblings ...)
2023-10-10 4:00 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 9:09 ` rguenth at gcc dot gnu.org
2023-10-10 9:24 ` juzhe.zhong at rivai dot ai
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-10 9:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
CC| |rguenth at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];
so these. The lookup result is a STRING_CST object. I'm testing a patch.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (7 preceding siblings ...)
2023-10-10 9:09 ` rguenth at gcc dot gnu.org
@ 2023-10-10 9:24 ` juzhe.zhong at rivai dot ai
2023-10-10 9:32 ` rguenther at suse dot de
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 9:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #8)
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
> vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];
>
> so these. The lookup result is a STRING_CST object. I'm testing a patch.
I have compare and debug between ARM SVE and RVV.
It seems that ARM SVE produce result of visit_reference_op_load is
CONST_VECTOR:
(gdb) p debug(to)
{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
(gdb) p to->typed.type->type_common.mode
$23 = E_V16QImode
However, RVV produce result of visit_reference_op_load is STRING_CST:
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
This is the BLKmode.
Could you tell me where I should fix in RISC-V backend?
It seems that it is not middle-end issue.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (8 preceding siblings ...)
2023-10-10 9:24 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 9:32 ` rguenther at suse dot de
2023-10-10 10:38 ` cvs-commit at gcc dot gnu.org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenther at suse dot de @ 2023-10-10 9:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 10 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
>
> --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to Richard Biener from comment #8)
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
> > vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];
> >
> > so these. The lookup result is a STRING_CST object. I'm testing a patch.
>
> I have compare and debug between ARM SVE and RVV.
> It seems that ARM SVE produce result of visit_reference_op_load is
> CONST_VECTOR:
>
> (gdb) p debug(to)
> { 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
> (gdb) p to->typed.type->type_common.mode
> $23 = E_V16QImode
>
> However, RVV produce result of visit_reference_op_load is STRING_CST:
>
> (gdb) p debug (result)
> "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
>
> This is the BLKmode.
>
> Could you tell me where I should fix in RISC-V backend?
> It seems that it is not middle-end issue.
The IL into the SVE case is likely different. The difference is
wheher we have a direct hashtable hit for the load or whether we
need to go through vn_reference_lookup_3 which will perform the
type punning on its own.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (9 preceding siblings ...)
2023-10-10 9:32 ` rguenther at suse dot de
@ 2023-10-10 10:38 ` cvs-commit at gcc dot gnu.org
2023-10-10 10:50 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-10 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:7c76c876e917a1f20a788f602cc78fff7d0a2a65
commit r14-4527-g7c76c876e917a1f20a788f602cc78fff7d0a2a65
Author: Richard Biener <rguenther@suse.de>
Date: Tue Oct 10 11:09:16 2023 +0200
Fix missed CSE with a BLKmode entity
The following fixes fallout of r10-7145-g1dc00a8ec9aeba which made
us cautionous about CSEing a load to an object that has padding bits.
The added check also triggers for BLKmode entities like STRING_CSTs
but by definition a BLKmode entity does not have padding bits.
PR tree-optimization/111751
* tree-ssa-sccvn.cc (visit_reference_op_load): Exempt
BLKmode result from the padding bits check.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (10 preceding siblings ...)
2023-10-10 10:38 ` cvs-commit at gcc dot gnu.org
@ 2023-10-10 10:50 ` rguenth at gcc dot gnu.org
2023-10-10 11:17 ` juzhe.zhong at rivai dot ai
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-10 10:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed. Feel free to add a RISC-V specific testcase so we don't
regress.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (11 preceding siblings ...)
2023-10-10 10:50 ` rguenth at gcc dot gnu.org
@ 2023-10-10 11:17 ` juzhe.zhong at rivai dot ai
2023-10-10 11:23 ` juzhe.zhong at rivai dot ai
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 11:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #13 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Thanks, Richi.
It does fix this issue.
This patch seems to cause an ICE in RISC-V:
#include <stdint-gcc.h>
#include <assert.h>
#define N 128
int
main ()
{
uint8_t mask[N]
= {0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1};
uint8_t out[N] = {0};
for (uint8_t i = 0; i < N; ++i)
if (mask[i])
out[i] = i;
for (uint8_t i = 0; i < N; ++i)
{
if (mask[i])
assert (out[i] == i);
else
assert (out[i] == 0);
}
}
riscv64-unknown-elf-gcc --param riscv-autovec-preference=fixed-vlmax --param
riscv-autovec-lmul=m8 -O3 -S auto.c
during GIMPLE pass: fre
auto.c: In function 'main':
auto.c:7:1: internal compiler error: in execute_todo, at passes.cc:2137
7 | main ()
| ^~~~
0x1714290 execute_todo
../../../../gcc/gcc/passes.cc:2137
I guess this is caused by this following IR:
mask =
"\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01";
out = "\x00";
_51 = VIEW_CONVERT_EXPR<vector(128) unsigned
char>("\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01");
mask__27.12_47 = _51 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0 };
.MASK_LEN_STORE (&out, 8B, mask__27.12_47, 128, 0, { 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127 });
There is a VIEW_CONVERT_EXPR here.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (12 preceding siblings ...)
2023-10-10 11:17 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 11:23 ` juzhe.zhong at rivai dot ai
2023-10-10 11:40 ` juzhe.zhong at rivai dot ai
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 11:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #14 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Also this case ICE:
typedef unsigned char __attribute__((vector_size(4))) uvec;
int main (int argc, char *argv[]) {
int i;
int x = 0;
uvec uc0 = (uvec) {argc, 1, 2, 10};
unsigned char uc1[4] = {0, 3, 2, 200};
signed char ucg[4] = {1, 0, 0, 0 };
signed char ucl[4] = {0, 1, 0, 1 };
#define uc0_ ((unsigned char *)&uc0)
for (i = 0; i < 4; i ++) {
x |= ucg[i] != (uc0_[i] > uc1[i]);
x |= ucl[i] != (uc0_[i] < uc1[i]);
}
return x;
}
during GIMPLE pass: isel
dump file: auto.c.256t.isel
auto.c: In function 'main':
auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:328
3 | int main (int argc, char *argv[]) {
| ^~~~
0x1bb55bd gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:325
0x1bb57c6 execute
../../../../gcc/gcc/gimple-isel.cc:390
Looks odd, it ICE at gimple-isel.cc:
gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (13 preceding siblings ...)
2023-10-10 11:23 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 11:40 ` juzhe.zhong at rivai dot ai
2023-10-10 11:49 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #15 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Also, I find this following case that ARM SVE failed to optimize:
https://godbolt.org/z/d6YnneETj
#define N 16
typedef int half_word;
int foo2 ()
{
int i;
half_word ia[N];
half_word ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
half_word ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
/* Not worthwhile, only 2 parts per int */
for (i = 0; i < N; i++)
{
ia[i] = ib[i] + ic[i];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (ia[i] != ib[i] + ic[i])
abort ();
}
return 0;
}
I guess your approach can fix that for ARM SVE. Maybe ARM SVE can also add
this case too.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (14 preceding siblings ...)
2023-10-10 11:40 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 11:49 ` rguenth at gcc dot gnu.org
2023-10-10 11:50 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-10 11:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #14)
> Also this case ICE:
>
> typedef unsigned char __attribute__((vector_size(4))) uvec;
>
> int main (int argc, char *argv[]) {
> int i;
> int x = 0;
> uvec uc0 = (uvec) {argc, 1, 2, 10};
> unsigned char uc1[4] = {0, 3, 2, 200};
> signed char ucg[4] = {1, 0, 0, 0 };
> signed char ucl[4] = {0, 1, 0, 1 };
>
> #define uc0_ ((unsigned char *)&uc0)
>
> for (i = 0; i < 4; i ++) {
> x |= ucg[i] != (uc0_[i] > uc1[i]);
> x |= ucl[i] != (uc0_[i] < uc1[i]);
> }
> return x;
> }
>
> during GIMPLE pass: isel
> dump file: auto.c.256t.isel
> auto.c: In function 'main':
> auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> gimple-isel.cc:328
> 3 | int main (int argc, char *argv[]) {
> | ^~~~
> 0x1bb55bd gimple_expand_vec_cond_expr
> ../../../../gcc/gcc/gimple-isel.cc:325
> 0x1bb57c6 execute
> ../../../../gcc/gcc/gimple-isel.cc:390
>
>
> Looks odd, it ICE at gimple-isel.cc:
>
> gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
I have a fix for the first issue. For this one the issue seems to be that
we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
selection for
mask__11.18_97 = VEC_COND_EXPR <mask__9.15_92, { 0, -1, -1, -1 }, { -1, 0, 0, 0
}>;
note the value is of vector boolean type. But we fail to have
vcond_maskV4BIV4BI.
ISTR we have fixed sth similar
by adding missing patterns with VnBImode result? But maybe forgot about
VLS modes here?
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (15 preceding siblings ...)
2023-10-10 11:49 ` rguenth at gcc dot gnu.org
@ 2023-10-10 11:50 ` cvs-commit at gcc dot gnu.org
2023-10-10 11:56 ` juzhe.zhong at rivai dot ai
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-10 11:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Lehua Ding <lhtin@gcc.gnu.org>:
https://gcc.gnu.org/g:a704603d458b1e55b561ddfb4e513581ee863ed6
commit r14-4528-ga704603d458b1e55b561ddfb4e513581ee863ed6
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date: Tue Oct 10 19:47:06 2023 +0800
RISC-V: Add testcase for SCCVN optimization[PR111751]
Add testcase for PR111751 which has been fixed:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632474.html
PR target/111751
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr111751.c: New test.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (16 preceding siblings ...)
2023-10-10 11:50 ` cvs-commit at gcc dot gnu.org
@ 2023-10-10 11:56 ` juzhe.zhong at rivai dot ai
2023-10-10 12:20 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 11:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #18 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #16)
> (In reply to JuzheZhong from comment #14)
> > Also this case ICE:
> >
> > typedef unsigned char __attribute__((vector_size(4))) uvec;
> >
> > int main (int argc, char *argv[]) {
> > int i;
> > int x = 0;
> > uvec uc0 = (uvec) {argc, 1, 2, 10};
> > unsigned char uc1[4] = {0, 3, 2, 200};
> > signed char ucg[4] = {1, 0, 0, 0 };
> > signed char ucl[4] = {0, 1, 0, 1 };
> >
> > #define uc0_ ((unsigned char *)&uc0)
> >
> > for (i = 0; i < 4; i ++) {
> > x |= ucg[i] != (uc0_[i] > uc1[i]);
> > x |= ucl[i] != (uc0_[i] < uc1[i]);
> > }
> > return x;
> > }
> >
> > during GIMPLE pass: isel
> > dump file: auto.c.256t.isel
> > auto.c: In function 'main':
> > auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> > gimple-isel.cc:328
> > 3 | int main (int argc, char *argv[]) {
> > | ^~~~
> > 0x1bb55bd gimple_expand_vec_cond_expr
> > ../../../../gcc/gcc/gimple-isel.cc:325
> > 0x1bb57c6 execute
> > ../../../../gcc/gcc/gimple-isel.cc:390
> >
> >
> > Looks odd, it ICE at gimple-isel.cc:
> >
> > gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
>
> I have a fix for the first issue. For this one the issue seems to be that
> we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
> selection for
>
> mask__11.18_97 = VEC_COND_EXPR <mask__9.15_92, { 0, -1, -1, -1 }, { -1, 0,
> 0, 0 }>;
>
> note the value is of vector boolean type. But we fail to have
> vcond_maskV4BIV4BI.
>
> ISTR we have fixed sth similar
> by adding missing patterns with VnBImode result? But maybe forgot about
> VLS modes here?
Confirm the second issue is fixed after I added vcond_mask of VLS BOOL mask
mode
I will commit it after I finish RISC-V regression.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (17 preceding siblings ...)
2023-10-10 11:56 ` juzhe.zhong at rivai dot ai
@ 2023-10-10 12:20 ` cvs-commit at gcc dot gnu.org
2023-10-10 12:22 ` cvs-commit at gcc dot gnu.org
2023-10-10 12:47 ` juzhe.zhong at rivai dot ai
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-10 12:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:70b5c6981fcdff246f90e57e91f3e1667eab2eb3
commit r14-4537-g70b5c6981fcdff246f90e57e91f3e1667eab2eb3
Author: Richard Biener <rguenther@suse.de>
Date: Tue Oct 10 13:33:34 2023 +0200
tree-optimization/111751 - support 1024 bit vector constant
reinterpretation
The following ups the limit in fold_view_convert_expr to handle
1024bit vectors as used by GCN and RVV. It also robustifies
the handling in visit_reference_op_load to properly give up when
constants cannot be re-interpreted.
PR tree-optimization/111751
* fold-const.cc (fold_view_convert_expr): Up the buffer size
to 128 bytes.
* tree-ssa-sccvn.cc (visit_reference_op_load): Special case
constants, giving up when re-interpretation to the target type
fails.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (18 preceding siblings ...)
2023-10-10 12:20 ` cvs-commit at gcc dot gnu.org
@ 2023-10-10 12:22 ` cvs-commit at gcc dot gnu.org
2023-10-10 12:47 ` juzhe.zhong at rivai dot ai
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-10 12:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Lehua Ding <lhtin@gcc.gnu.org>:
https://gcc.gnu.org/g:5255273ee8b14ea565eb43f067a86370d25df114
commit r14-4538-g5255273ee8b14ea565eb43f067a86370d25df114
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date: Tue Oct 10 20:15:35 2023 +0800
RISC-V: Add VLS BOOL mode vcond_mask[PR111751]
Richard patch resolve PR111751:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c76c876e917a1f20a788f602cc78fff7d0a2a65
which cause ICE in RISC-V regression:
FAIL: gcc.dg/torture/pr53144.c -O2 (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
FAIL: gcc.dg/torture/pr53144.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:328)
FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gcc.dg/torture/pr53144.c -O3 -g (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
FAIL: gcc.dg/torture/pr53144.c -O3 -g (test for excess errors)
VLS BOOL modes vcond_mask is needed to fix this regression ICE.
More details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Tested and Committed.
PR target/111751
gcc/ChangeLog:
* config/riscv/autovec.md: Add VLS BOOL modes.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
2023-10-10 3:19 [Bug c/111751] New: RISC-V: RVV unexpected vectorization juzhe.zhong at rivai dot ai
` (19 preceding siblings ...)
2023-10-10 12:22 ` cvs-commit at gcc dot gnu.org
@ 2023-10-10 12:47 ` juzhe.zhong at rivai dot ai
20 siblings, 0 replies; 22+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-10 12:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #21 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Hi, Richi.
Finish and confirm RISC-V regression.
All pass.
Thank you so much!
^ permalink raw reply [flat|nested] 22+ messages in thread