[Bug tree-optimization/97717] New: compilation with -O(1/2/3) flag failed while -O0 succeeds

[Bug tree-optimization/97717] New: compilation with -O(1/2/3) flag failed while -O0 succeeds

[kranti.rkiran at gmail dot com]

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

            Bug ID: 97717
           Summary: compilation with -O(1/2/3) flag failed while -O0
                    succeeds
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kranti.rkiran at gmail dot com
  Target Milestone: ---

GCC version: 9.3.0

System Info: 
System:    Host: T-RAGOLI-X1Yoga Kernel: 4.4.0-18362-Microsoft x86_64 bits: 64 
           Console: tty 2 Distro: Ubuntu 20.04 LTS (Focal Fossa) 
CPU:       Topology: Dual Core model: Intel Core i7-6600U bits: 64 type: MT MCP 
           L2 cache: 256 KiB 
           Speed: 2808 MHz min/max: N/A Core speeds (MHz): 1: 2808 2: 2808 3:
2808 4: 2808 
(The machine uses WSL-2)

Compiling the source code with optimization fags (-O1/-O2/-O3) throws a
compiler segfault.
Command: g++ -O3 test.cpp
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus

The compilation using 'g++ test.cpp' succeeds.

[Bug tree-optimization/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[kranti.rkiran at gmail dot com]

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

Rahul Kranti Kiran <kranti.rkiran at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kranti.rkiran at gmail dot com

--- Comment #1 from Rahul Kranti Kiran <kranti.rkiran at gmail dot com> ---
Created attachment 49501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49501&action=edit
The compressed version of the preprocessed file generated by running 'g++
--save-temps -O3 test.cpp'.

[Bug tree-optimization/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-11-05

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
What's the stack limit for processes under WSL-2?  Try ulimit -s unlimited.

Otherwise it's hard to say what goes wrong without a backtrace, I can't
reproduce
on x86_64-linux.  But the testcase complains about uses of 'auto' and suggests
-fconcepts (which doesn't mitigate them).  Are you really using plain -O3?

[Bug tree-optimization/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[kranti.rkiran at gmail dot com]

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

--- Comment #3 from Rahul Kranti Kiran <kranti.rkiran at gmail dot com> ---
The stack size was 8 KB and 'ulimit -s unlimited'  worked for root but gets
reset as soon as I got back to the userspace.

Running the compilation with unlimited stack still threw a SEGFAULT. 

The complete output of ulimit -a, when running as a root. 

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7823
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 7823
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Yes, the compilation was just using -O3 flag.
Apologies for the delayed reply.

[Bug tree-optimization/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
           Keywords|                            |compile-time-hog

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
for me, -O1 takes a long time even:
 callgraph ipa passes               :   2.34 ( 26%)   0.49 ( 30%)   2.84 ( 26%)
  159M ( 37%)


-O2 is much worse:
 alias stmt walking                 :  23.12 ( 37%)   0.14 (  7%)  23.24 ( 36%)
  323M ( 17%)
 tree DSE                           :  11.34 ( 18%)   0.00 (  0%)  11.36 ( 18%)
   15k (  0%)
 tree slp vectorization             :  16.01 ( 26%)   0.30 ( 15%)  16.32 ( 25%)
 1117M ( 60%)

This is with --enable-checking=yes but with -fno-checking.


So there is at least a compile time hog here.

[Bug middle-end/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |middle-end

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
For -O3 the following is bad too:
 load CSE after reload              :  32.11 ( 34%)   0.00 (  0%)  32.11 ( 33%)
 5808  (  0%)

[Bug middle-end/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
fillLUTDIV is basically one big function (one BB) which does:

inp[...] = ...;
1019 times

fillLUTNEGEXP does the same thing 33659 times.


I assume these are generated functions. It might be better to have static const
array which you do a copy from, either memcpy or somehow ever. This will
improve the compile time speed by a lot and maybe even the runtime speed too.

[Bug middle-end/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |54896
           Keywords|                            |alias

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> fillLUTDIV is basically one big function (one BB) which does:
> 
> inp[...] = ...;
> 1019 times
> 
> fillLUTNEGEXP does the same thing 33659 times.

Which makes this very similar to PR 54896 for at least "alias stmt walking"
time.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54896
[Bug 54896] optimization slowness on large basic blocks