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

            Bug ID: 92657
           Summary: High stack usage due ftree-ch
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adhemerval.zanella at linaro dot org
  Target Milestone: ---

Created attachment 47351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47351&action=edit
High stack usage due ftree-ch

The code snippet (gcc_free_ch_stack.c) shows a high stack usage.  With GCC
9.2.1 I see the resulting stack usage using -fstack-usage along with -O2:

arm                     632
aarch64                 448
powerpc                 912
powerpc64le             560
s390                    600
s390x                   632
i386                    1376
x86_64                  784

The same issue also shows in master branch. It seems that it is due -ftree-ch
pass with feeds -ftree-loop-im, -ftree-pre, -fmove-loop-invariants, and -fgcse.
Andrew Pinski suggested is mostly due lack of a good estimate register pressure
for loop invariant code motion.

Andrew also suggested to use -fno-tree-loop-im -fno-tree-pre -fno-gcse, however
even with this options the resulting stack usage does not get in par with -Os
option (which disables -ftree-ch).  On powerpc64le:

$ ./gcc/xgcc -v 2>&1 | grep 'gcc version'
gcc version 10.0.0 20191121 (experimental) (GCC) 

$ ./gcc/xgcc -B gcc -O2 stack_usage.c -fstack-usage -c; cat stack_usage.su
stack_usage.c:157:6:mlx5e_grp_sw_update_stats   496     static

$ ./gcc/xgcc -B gcc -O2 stack_usage.c -fstack-usage -c -fno-tree-loop-im
-fno-tree-pre -fno-move-loop-invariants -fno-gcse; cat stack_usage.su
stack_usage.c:157:6:mlx5e_grp_sw_update_stats   176     static$ ./gcc/xgcc -B
gcc -Os stack_usage.c -fstack-usage -c; cat stack_usage.su

$ ./gcc/xgcc -B gcc -Os stack_usage.c -fstack-usage -c; cat stack_usage.su
stack_usage.c:157:6:mlx5e_grp_sw_update_stats   32      static

Reply via email to