[Bug middle-end/111975] New: gimple front end can't round-trip vectorized code

[Bug middle-end/111975] New: gimple front end can't round-trip vectorized code

[acoplan at gcc dot gnu.org]

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.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

[rguenth at gcc dot gnu.org]

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.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

[rguenth at gcc dot gnu.org]

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).

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

[cvs-commit at gcc dot gnu.org]

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.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

[cvs-commit at gcc dot gnu.org]

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.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

[rguenth at gcc dot gnu.org]

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.