public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code
@ 2023-10-25 9:39 acoplan at gcc dot gnu.org
2023-10-25 13:03 ` [Bug middle-end/111975] " rguenth at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: acoplan at gcc dot gnu.org @ 2023-10-25 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
Bug ID: 111975
Summary: gimple front end can't round-trip vectorized code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Take the following testcase on aarch64:
void foo(int *restrict a, int *restrict b, int *restrict c)
{
for (int i = 0; i < 256; i++)
a[i] = b[i] + c[i];
}
compiled with -O2 -fdump-tree-optimized-gimple, we get the IR:
void __GIMPLE (ssa,guessed_local(10737416))
foo (int * restrict a, int * restrict b, int * restrict c)
{
sizetype ivtmp.17;
vector(4) int vect__8.10;
vector(4) int vect__6.9;
vector(4) int vect__4.6;
__BB(2,guessed_local(10737416)):
goto __BB3(precise(134217728));
__BB(3,loop_header(1),guessed_local(687194626)):
ivtmp.17_23 = __PHI (__BB3: ivtmp.17_19, __BB2: 0ul);
vect__4.6_9 = MEM <vector(4) int> [(int *)b_12(D) + ivtmp.17_23 * 1];
vect__6.9_27 = MEM <vector(4) int> [(int *)c_13(D) + ivtmp.17_23 * 1];
vect__8.10_28 = vect__4.6_9 + vect__6.9_27;
MEM <vector(4) int> [(int *)a_14(D) + ivtmp.17_23 * 1] = vect__8.10_28;
ivtmp.17_19 = ivtmp.17_23 + 16ul;
if (ivtmp.17_19 != 1024ul)
goto __BB3(guessed(132120577));
else
goto __BB4(guessed(2097151));
__BB(4,guessed_local(10737416)):
return;
}
but trying to compile this with -fgimple shows several problems:
- the type sizetype isn't known.
- ivtmp.17 isn't accepted as a variable name (indeed none of the variables
with . in the name are accepted).
- the type vector(4) int isn't understood by the gimple FE.
If I fix these issues by declaring the types as follows:
typedef unsigned long sizetype;
typedef int __attribute__((vector_size(16))) V;
and substituting all uses of the old type names, and also rename all variables
to replace . with _, then it is nearly accepted. One remaining problem seems to
be that the MEM syntax isn't accepted:
vect__4_6_9 = MEM <V> [(int *)b_12(D) + ivtmp_17_23 * 1];
gives:
error: 'MEM' undeclared (first use in this function)
and attempting to convert the MEM to use something closer to the syntax in the
gcc.dg/gimplefe-* tests, this still fails:
vect__4_6_9 = __MEM <V> ((int *)b_12(D) + ivtmp_17_23 * 1);
is rejected with:
error: expected ')' before '*' token
. It would be good if these issues could be fixed so that optimized gimple can
be round-tripped without laborious manual fixing of the input. Even with that,
it's still not clear how to make the MEM expressions here get accepted.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/111975] gimple front end can't round-trip vectorized code
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
@ 2023-10-25 13:03 ` rguenth at gcc dot gnu.org
2023-10-25 13:04 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-25 13:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-10-25
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alex Coplan from comment #0)
> Take the following testcase on aarch64:
>
> void foo(int *restrict a, int *restrict b, int *restrict c)
> {
> for (int i = 0; i < 256; i++)
> a[i] = b[i] + c[i];
> }
>
> compiled with -O2 -fdump-tree-optimized-gimple, we get the IR:
>
> void __GIMPLE (ssa,guessed_local(10737416))
> foo (int * restrict a, int * restrict b, int * restrict c)
> {
> sizetype ivtmp.17;
There's __SIZETYPE__ available for this (for portability)
> vector(4) int vect__8.10;
> vector(4) int vect__6.9;
> vector(4) int vect__4.6;
>
> __BB(2,guessed_local(10737416)):
> goto __BB3(precise(134217728));
>
> __BB(3,loop_header(1),guessed_local(687194626)):
> ivtmp.17_23 = __PHI (__BB3: ivtmp.17_19, __BB2: 0ul);
> vect__4.6_9 = MEM <vector(4) int> [(int *)b_12(D) + ivtmp.17_23 * 1];
It should be __MEM, not sure why that's not (longer?) dumped correctly.
> vect__6.9_27 = MEM <vector(4) int> [(int *)c_13(D) + ivtmp.17_23 * 1];
> vect__8.10_28 = vect__4.6_9 + vect__6.9_27;
> MEM <vector(4) int> [(int *)a_14(D) + ivtmp.17_23 * 1] = vect__8.10_28;
> ivtmp.17_19 = ivtmp.17_23 + 16ul;
> if (ivtmp.17_19 != 1024ul)
> goto __BB3(guessed(132120577));
> else
> goto __BB4(guessed(2097151));
>
> __BB(4,guessed_local(10737416)):
> return;
>
> }
>
> but trying to compile this with -fgimple shows several problems:
>
> - the type sizetype isn't known.
> - ivtmp.17 isn't accepted as a variable name (indeed none of the variables
> with . in the name are accepted).
Yeah ... rename them
> - the type vector(4) int isn't understood by the gimple FE.
You need C frontend like typedefs, basically any not basic type needs to be
manually declared (we don't output type declarations when dumping)
> If I fix these issues by declaring the types as follows:
>
> typedef unsigned long sizetype;
> typedef int __attribute__((vector_size(16))) V;
>
> and substituting all uses of the old type names, and also rename all
> variables to replace . with _, then it is nearly accepted. One remaining
> problem seems to be that the MEM syntax isn't accepted:
>
> vect__4_6_9 = MEM <V> [(int *)b_12(D) + ivtmp_17_23 * 1];
>
> gives:
>
> error: 'MEM' undeclared (first use in this function)
>
> and attempting to convert the MEM to use something closer to the syntax in
> the gcc.dg/gimplefe-* tests, this still fails:
>
> vect__4_6_9 = __MEM <V> ((int *)b_12(D) + ivtmp_17_23 * 1);
>
> is rejected with:
>
> error: expected ')' before '*' token
Ah, it's a TARGET_MEM_REF! Parsing that isn't supported. I suggest to
dump before IVOPTs instead.
>
> . It would be good if these issues could be fixed so that optimized gimple
> can be round-tripped without laborious manual fixing of the input. Even with
> that, it's still not clear how to make the MEM expressions here get accepted.
I'll make TARGET_MEM_REF supported.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/111975] gimple front end can't round-trip vectorized code
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
2023-10-25 13:03 ` [Bug middle-end/111975] " rguenth at gcc dot gnu.org
@ 2023-10-25 13:04 ` rguenth at gcc dot gnu.org
2023-12-18 12:00 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-25 13:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 56252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56252&action=edit
old patch
If you use sth like startswith("vect") you'll figure LC-SSA doesn't work -
here's a quite old patch supporting it (but it was late during stage3 and had
no actual usecase yet).
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/111975] gimple front end can't round-trip vectorized code
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
2023-10-25 13:03 ` [Bug middle-end/111975] " rguenth at gcc dot gnu.org
2023-10-25 13:04 ` rguenth at gcc dot gnu.org
@ 2023-12-18 12:00 ` cvs-commit at gcc dot gnu.org
2023-12-18 14:40 ` cvs-commit at gcc dot gnu.org
2023-12-18 14:41 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-18 12:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
--- Comment #3 from GCC 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:5bca321faa30c4fb46225efbe2698a13b3271b1c
commit r14-6658-g5bca321faa30c4fb46225efbe2698a13b3271b1c
Author: Richard Biener <rguenther@suse.de>
Date: Mon Dec 18 11:41:03 2023 +0100
c/111975 - GIMPLE FE dumping and parsing of TARGET_MEM_REF
The following adds dumping of TARGET_MEM_REF in -gimple form and
adds parsing of it to the GIMPLE FE.
PR c/111975
gcc/c/
* gimple-parser.cc (c_parser_gimple_postfix_expression):
Parse TARGET_MEM_REF extended operands for __MEM.
gcc/
* tree-pretty-print.cc (dump_mem_ref): Use TDF_GIMPLE path
also for TARGET_MEM_REF and amend it.
gcc/testsuite/
* gcc.dg/gimplefe-52.c: New testcase.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/111975] gimple front end can't round-trip vectorized code
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
` (2 preceding siblings ...)
2023-12-18 12:00 ` cvs-commit at gcc dot gnu.org
@ 2023-12-18 14:40 ` cvs-commit at gcc dot gnu.org
2023-12-18 14:41 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-18 14:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
--- Comment #4 from GCC 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:88a398a487ee37f1fc7850740f2d94d895657646
commit r14-6662-g88a398a487ee37f1fc7850740f2d94d895657646
Author: Richard Biener <rguenther@suse.de>
Date: Mon Dec 18 13:40:46 2023 +0100
middle-end/111975 - dump -> GIMPLE FE roundtrip improvements
The following improves the manual work needed to make a -gimple dump
valid input to the GIMPLE FE. First of all it recognizes the 'sizetype'
tree and dumps it as __SIZETYPE__, then it changes dumping vector types
without name from 'vector(n) T' to 'T [[gnu::vector_size(n')]]' which
we can parse in most relevant contexts (and that's shorter than
using __attribute__). Third it avoids a NULL_TREE TMR_STEP when
it would be one, an optimization that's re-done when generating RTL.
PR middle-end/111975
* tree-pretty-print.cc (dump_generic_node): Dump
sizetype as __SIZETYPE__ with TDF_GIMPLE.
Dump unnamed vector types as T [[gnu::vector_size(n)]] with
TDF_GIMPLE.
* tree-ssa-address.cc (create_mem_ref_raw): Never generate
a NULL STEP when INDEX is specified.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/111975] gimple front end can't round-trip vectorized code
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
` (3 preceding siblings ...)
2023-12-18 14:40 ` cvs-commit at gcc dot gnu.org
@ 2023-12-18 14:41 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-18 14:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111975
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
What's left is the dots.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-12-18 14:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-25 9:39 [Bug middle-end/111975] New: gimple front end can't round-trip vectorized code acoplan at gcc dot gnu.org
2023-10-25 13:03 ` [Bug middle-end/111975] " rguenth at gcc dot gnu.org
2023-10-25 13:04 ` rguenth at gcc dot gnu.org
2023-12-18 12:00 ` cvs-commit at gcc dot gnu.org
2023-12-18 14:40 ` cvs-commit at gcc dot gnu.org
2023-12-18 14:41 ` rguenth at gcc dot gnu.org
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).