https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #5 from Jan Hubicka ---
For a summary
- PR109491 does not seem to be about integration time. most time is RTL PRE.
- PR108086 has 10% spent in integration and seems to be operand scan issue
- PR99785 is hard to judge given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #4 from Richard Biener ---
when working on another testcase I noticed our inlining itself creates a lot of
garbage - copies can pile up, esp. when not optimizing. The PR79416 testcase
is similar than yours but using asm("nop") and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #2 from Richard Biener ---
Possible issues specific to GCC that LLVM maybe avoids are:
Another probably more common with C++ code issue would be that we
inline into not optimized callers which means calls that are
almost trivially u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #1 from Chip Kerchner ---
Just for note: The same code that has heavy use always_inline compiles about
3X faster in LLVM and uses about 2X less memory to compile.
