public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/91257] Compile-time and memory-hog hog
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
@ 2020-12-11 17:36 ` rogerio.souza at gmail dot com
2020-12-11 17:38 ` rogerio.souza at gmail dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: rogerio.souza at gmail dot com @ 2020-12-11 17:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257
Rogério de Souza Moraes <rogerio.souza at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rogerio.souza at gmail dot com
--- Comment #12 from Rogério de Souza Moraes <rogerio.souza at gmail dot com> ---
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?
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)?
- 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?
- 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?
We appreciate very much any feedback.
Best regards,
--
Rogerio
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/91257] Compile-time and memory-hog hog
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
2020-12-11 17:36 ` [Bug tree-optimization/91257] Compile-time and memory-hog hog rogerio.souza at gmail dot com
@ 2020-12-11 17:38 ` rogerio.souza at gmail dot com
2020-12-11 17:40 ` rogerio.souza at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: rogerio.souza at gmail dot com @ 2020-12-11 17:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257
--- Comment #13 from Rogério de Souza Moraes <rogerio.souza at gmail dot com> ---
Created attachment 49746
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49746&action=edit
File that reproduces the current structure and has performance issues.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/91257] Compile-time and memory-hog hog
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
2020-12-11 17:36 ` [Bug tree-optimization/91257] Compile-time and memory-hog hog rogerio.souza at gmail dot com
2020-12-11 17:38 ` rogerio.souza at gmail dot com
@ 2020-12-11 17:40 ` rogerio.souza at gmail dot com
2021-01-04 7:54 ` rguenth at gcc dot gnu.org
2024-02-19 13:26 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: rogerio.souza at gmail dot com @ 2020-12-11 17:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257
--- Comment #14 from Rogério de Souza Moraes <rogerio.souza at gmail dot com> ---
Created attachment 49747
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49747&action=edit
File which all the 'try' macros are taken out to separate routines, for build
performance improvement
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/91257] Compile-time and memory-hog hog
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-12-11 17:40 ` rogerio.souza at gmail dot com
@ 2021-01-04 7:54 ` rguenth at gcc dot gnu.org
2024-02-19 13:26 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-04 7:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/91257] Compile-time and memory-hog hog
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-01-04 7:54 ` rguenth at gcc dot gnu.org
@ 2024-02-19 13:26 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-02-19 13:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2019-07-25 00:00:00 |2024-2-19
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Still about the same with upcoming GCC 14.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-02-19 13:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-91257-4@http.gcc.gnu.org/bugzilla/>
2020-12-11 17:36 ` [Bug tree-optimization/91257] Compile-time and memory-hog hog rogerio.souza at gmail dot com
2020-12-11 17:38 ` rogerio.souza at gmail dot com
2020-12-11 17:40 ` rogerio.souza at gmail dot com
2021-01-04 7:54 ` rguenth at gcc dot gnu.org
2024-02-19 13:26 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).