[Bug target/99544] New: [11 Regression] ICE in expand_mult, at expmed.c:3582

[Bug target/99544] New: [11 Regression] ICE in expand_mult, at expmed.c:3582

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

            Bug ID: 99544
           Summary: [11 Regression] ICE in expand_mult, at expmed.c:3582
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc-11.0.1-alpha20210307 snapshot (g:a18ebd6c439227b048a91fbfa66f5983f884c157)
ICEs when compiling the following testcase, extracted from
libgomp/testsuite/libgomp.c-c++-common/pr66199-2.c, w/ -Os -fopenmp:

void
f2 (long a, long b, long c)
{
  long d, e;
  #pragma omp teams distribute parallel for simd firstprivate (a, b, c)
lastprivate(e)
  for (d = a; d < b; d++)
    e = c + d * 5;
}

% aarch64-linux-gnu-gcc-11.0.1 -Os -fopenmp -c drqo2auz.c
during RTL pass: expand
drqo2auz.c: In function 'f2._omp_fn.1':
drqo2auz.c:7:7: internal compiler error: in expand_mult, at expmed.c:3582
    7 |     e = c + d * 5;
      |     ~~^~~~~~~~~~~
0x6cd56b expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expmed.c:3582
0xb39874 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:9211
0xb3f39a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:10210
0xb3a735 expand_expr
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.h:282
0xb3a735 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:8789
0xb3f39a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:10210
0xb49214 expand_expr
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.h:282
0xb49214 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:8110
0xb37be8 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/expr.c:9013
0xa12f85 expand_gimple_stmt_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/cfgexpand.c:3947
0xa12f85 expand_gimple_stmt
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/cfgexpand.c:4008
0xa18bfa expand_gimple_basic_block
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/cfgexpand.c:6045
0xa1a79f execute
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210307/work/gcc-11-20210307/gcc/cfgexpand.c:6729

[Bug target/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

[Bug target/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[eochoa at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #1 from Erick Ochoa <eochoa at gcc dot gnu.org> ---
Hi,

I have an ICE on this assertion as well, but I found it by compiling x264_r
with the following flags

```
   OPTIMIZE         = -g -Ofast -funroll-loops -flto
   COPTIMIZE        = --param early-inlining-insns=51
   PASS1_FLAGS      = -fprofile-generate
   PASS2_FLAGS      = -fprofile-use
```

I did a bisection and I think it might be related to commit
a11ef53238c8ebaab9a3fbf200cb8b5c997b473b.

Here is my stack trace. Please note that the assertion is in a different line
in the above commit, but it is the same assertion as the snapshot reported by
Arseny.

```
x264_src/encoder/analyse.c: In function 'x264_analyse_update_cache':
x264_src/encoder/analyse.c:3319:13: internal compiler error: in expand_mult, at
expmed.c:3575
 3319 | static void x264_analyse_update_cache( x264_t *h, x264_mb_analysis_t *a
 )
      |             ^
0x8797b3 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
        /home/eochoa/gcc/gcc/expmed.c:3575
0x8a33db expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/eochoa/gcc/gcc/expr.c:9205
0x75845f expand_gimple_stmt_1
        /home/eochoa/gcc/gcc/cfgexpand.c:3947
0x75845f expand_gimple_stmt
        /home/eochoa/gcc/gcc/cfgexpand.c:4008
0x75fa13 expand_gimple_basic_block
        /home/eochoa/gcc/gcc/cfgexpand.c:6045
0x761bc7 execute
        /home/eochoa/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: /home/eochoa/gcc-inst/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [/home/eochoa/cpu2017-unmodified/benchspec/Makefile.defaults:337:
x264_r] Error 1
```

For me, the error is triggered:
* in the second compilation stage (i.e., when -fprofile-use is used)
* --param early-inlining-insns=51 needs to be set. Otherwise, the error is not
observed. I haven't tried with some lower values
* I haven't had the time to toggle the other flags, nor reduce the test case.

[Bug target/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think this is another case that the PR98287 proposed patch would fix, again
after vec lowering some pass (seems vrp2 in this case), this time it is the
/* Canonicalize X + (X << C) into X * (1 + (1 << C)) and
   (X << C1) + (X << C2) into X * ((1 << C1) + (1 << C2)).  */
match.pd rule, where the target apparently supports V2DImode left shift by
scalar constant and addition, but doesn't support V2DImode multiplication.
Maybe in this particular case it would be worth guarding the pattern on
existing optab for vector multiplication or disable it for vectors altogether
(apparently it was myself who has added that), because at least if the target
doesn't have particular vector multiplications, I'd say doing the additions and
shifts must be better than scalarizing it.  If multiplications are supported, I
guess best would be to let the expansion decide what is better, it has code to
turn scalar multiplications by constant into additions and shifts, so perhaps
could use that also for vector by uniform constants?

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-12
             Status|UNCONFIRMED                 |ASSIGNED
          Component|target                      |tree-optimization

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> I think this is another case that the PR98287 proposed patch would fix,
> again after vec lowering some pass (seems vrp2 in this case), this time it
> is the
> /* Canonicalize X + (X << C) into X * (1 + (1 << C)) and
>    (X << C1) + (X << C2) into X * ((1 << C1) + (1 << C2)).  */
> match.pd rule, where the target apparently supports V2DImode left shift by
> scalar constant and addition, but doesn't support V2DImode multiplication.
> Maybe in this particular case it would be worth guarding the pattern on
> existing optab for vector multiplication or disable it for vectors
> altogether (apparently it was myself who has added that), because at least
> if the target doesn't have particular vector multiplications, I'd say doing
> the additions and shifts must be better than scalarizing it.  If
> multiplications are supported, I guess best would be to let the expansion
> decide what is better, it has code to turn scalar multiplications by
> constant into additions and shifts, so perhaps could use that also for
> vector by uniform constants?

I think in general we should be careful with patterns for vector operations
since vector expressions tend to be "optimized" (by the user or by the
compiler).

In particular even before lvec in case the source expression is supported
by the target it's not good to turn it into sth unsupported.

Basic +- arithmetic and bitwise ops are usually fine since target support is
wide-spread but I'd argue against enabling more fancy cases (integer
mult/division, shifts) without vector support checks.

What is clear is that there's no convenient helper like
direct_internal_fn_supported_p for tree codes, we should aim at providing that
(see vectorizable_shift on how awkward this can be).

So in this particular case I suggest to disable the patter for vectors
(with a comment) and work on a way to guard it appropriately without
too much boiler-plate.

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50373
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50373&action=edit
gcc11-pr99544.patch

Patch that implements the *.pd part but not the expansion part (perhaps that
can be done in stage1).

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 12 Mar 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 50373
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50373&action=edit
> gcc11-pr99544.patch
> 
> Patch that implements the *.pd part but not the expansion part (perhaps that
> can be done in stage1).

LGTM

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:bbdf59fdbc2ce41ccfac807b15cf3fac7b465a56

commit r11-7656-gbbdf59fdbc2ce41ccfac807b15cf3fac7b465a56
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 13 08:56:15 2021 +0100

    match.pd: Don't optimize vector X + (X << C) -> X * (1 + (1 << C)) if there
is no mult support [PR99544]

    E.g. on aarch64, the target has V2DImode addition and shift by scalar
    optabs, but doesn't have V2DImode multiply.  The following testcase
    ICEs because this simplification is done after last lowering, but
    generally, even if it is done before that, turning it into a multiplication
    will not be an improvement because that means scalarization, while the
former
    can be done in vectors.

    It would be nice if we added expansion support for vector multiplication
    by uniform constants using shifts and additions like we have for scalar
    multiplication, but that is something that can be done in stage1.

    2021-03-13  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/99544
            * match.pd (X + (X << C) -> X * (1 + (1 << C))): Don't simplify
            if for vector types multiplication can't be done in type's mode.

            * gcc.dg/gomp/pr99544.c: New test.

[Bug tree-optimization/99544] [11 Regression] ICE in expand_mult, at expmed.c:3582

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.