[Bug tree-optimization/91257] Compile-time and memory-hog hog

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Rogério de Souza Moraes from comment #12)
> Hi Richard,
> 
> first, thank you for the great work improving the GCC performance.
> 
> The R&D team which I am working with provided two test cases, they show that
> it was possible to reduce the build time by taking out the block containing
> setjmp/longjmp to a separate routine, which is only called from the original
> routine.
> 
> Both attached files, example_base.c and example_routines.c, are generated in
> a very similar way, but in example_routines.c, all the 'try' macros are
> taken out to separate routines. 
> 
> The compilation times:
> example_base.c:
> v4.8.3 - 0m1.096s
> v6.3.0 - 0m16.017s
> v9.3.0 - 0m26.829s
> example_routines.c
> v4.8.3 - 0m0.955s
> v6.3.0 - 0m1.205s
> v9.3.0 - 0m1.617s
> 
> Is this approach ok to improve the build performance?

Yes, that avoids the complex CFG.

> Even if this approach is OK, there are still details unclear to us, and some
> might be not even known:
> 
> - Should we worry about inlining? Can we hint this to compiles, or should we
> make sure it's avoided (by using routine pointers, for example)?

In principle GCCs own heuristics should make sure it does not inline all
of the single-use routines but for extra safety I'd suggest to use

static void __attribute__((noinline))
routine_for_try_298(t__reg_s reg, int* v, int n0, int n1, int n2) {
    TRY_BEGIN {


> - Can we assume that routine call (with all low-level work like copying data
> on the stack etc.) is the only runtime performance price for this approach?

I think so, yes (make sure to declare the functions static as above so
the compiler can do IPA constant propagation, avoiding passing n0, n1, ..)

> - Is having many small routines instead of a few very large is universally
> good, or there are cases when it by itself can cause a problem?

You are trading a complex callgraph for a complex CFG (though in the
setjmp/longjmp case the CFG is artifically way more complex than the
callgraph variant), so in general you trade intra-FN compile-time for
inter-FN compile-time.  So yes, there could be similar issues in GCCs
IPA passes.

But while it is possible to short-cut all IPA optimization there are
select "transforms" on functions that do not scale well to arbitrary
large functions / complex CFGs.  A step further would decompose the
TU with the many small functions into multiple TUs (if you'd use LTO
for compiling then that's a no-op of course).

> We appreciate very much any feedback.
> 
> Best regards,
> --
> Rogerio