On Fri, Nov 22, 2019 at 2:40 PM Adhemerval Zanella adhemerval.zanella@linaro.org wrote:
Hi Arnd,
I took a look on the stack usage issue in the kernel snippet you provided [1], and as you have noted the most impact indeed come from -ftree-ch optimization. It is enabled in all optimization levels besides -Os (since besides possible increasing the stack usage it also might increase code side).
I am still fulling grasping what free-ch optimization does, but my understanding so far is it tries to reorganize the loop for later loop optimization phases. More specifically, what it ends up doing on the specific snippet is create extra stack variables for the internal membber access in the inner loop (which in its turns increase stack usage).
Thanks a lot for taking a detailed look!
This is also why adding the compiler barrier inhibits the optimization, since it prevents the ftree-ch to optimize the internal loop reorganization and it is passed as is to later optimizations phases.
It is also a generic pass that affects all architecture, albeit the resulting stack will depend on later passes. 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
Also, -fconserve-stack does not really help with this pass since ftree-ch does not check the flag usage. The fconserve-stack currently only seems to effect the inliner by setting both large-stack-frame and large-stack-frame-growth to some conservative values.
The straightforward change I am checking is just to disable tree-ch optimization if fconserve-stack is also enabled:
diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c index b894a7e0918..b14dd66257c 100644 --- a/gcc/tree-ssa-loop-ch.c +++ b/gcc/tree-ssa-loop-ch.c @@ -291,7 +291,8 @@ public: {}
/* opt_pass methods: */
- virtual bool gate (function *) { return flag_tree_ch != 0; }
virtual bool gate (function *) { return flag_tree_ch != 0
&& flag_conserve_stack == 0; }/* Initialize and finalize loop structures, copying headers inbetween. */ virtual unsigned int execute (function *);
That assumes that ftree-ch generally results in higher stack usage, which is something we would have to confirm first. I've done similar checks before on other options, basically building a large project like the kernel with -Wframe-larger-than=128 (or similar), and then comparing the warning output with/without that flag.
That would tell us whether this is a systematic problem with -ftree-ch (making your patch a good idea) or whether the example code just hit a worst case that is otherwise rare, and turning off -ftree-ch generally just leads to worse output but no lower stack usage.
One suspicion I have is that this is related to not only having a large struct, but also having lots of 64-bit members in that struct and working on it on a 32-bit architecture.
Arnd