[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351 --- Comment #5 from Martin Jambor --- If you rename main to something else, like bar, and so the calls to f outside of the loop are not considered cold, you get the GCC 12 behavior. Is this reduced from a real-world problem? Because on the testcase IPA-CP actually does what I would like it to do, it iginores the first parameter because really IPA-SRA is better placed to deal with it and then does not duplicate f for the cold calls. The fact that the GCC 12 heuristics first cloned for a constant in a useless parameter in the loop and then, when removing it in the other calls, it happened to find out that those two share the same constant in the second parameter, which happened to make the function shorter, is basically luck rather than design.
[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351 --- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org) --- > early inline pass inlines the two calls with C front-end but fails to inline > them with C++ front-end due to "growth 8 exceeds --param > early-inlining-insns divided by number of calls". > Swap C and C++ here...
[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Xionghu Luo (luoxhu at gcc dot gnu.org) changed:
What|Removed |Added
CC||yinyuefengyi at gmail dot com
--- Comment #3 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
(In reply to Andrew Pinski from comment #2)
> I noticed that with the C++ front-end early inline inlines f into main but
> with the C front-end it does not ...
C++ generates different call instructions with C front-end:
< D.3747 = f (7, 7);
< D.3748 = f (9, 7);
---
> f (7, 7);
> f (9, 7);
then an extra return_cost cost is added to C++ front-end:
< D.3747 = f (7, 7);
< freq:1.00 size: 4 time: 13
< D.3748 = f (9, 7);
< freq:1.00 size: 4 time: 13
---
> f (7, 7);
> freq:1.00 size: 3 time: 12
> f (9, 7);
> freq:1.00 size: 3 time: 12
early inline pass inlines the two calls with C front-end but fails to inline
them with C++ front-end due to "growth 8 exceeds --param early-inlining-insns
divided by number of calls".
gcc/ipa-inline.cc:747growth * (n + 1) > early_inlining_insns
gcc/opts.cc:687{ OPT_LEVELS_3_PLUS, OPT__param_early_inlining_insns_, NULL,
14 },
Tried revert the commit r13-4240-gfeeb0d68f1c708, the two calls still exits,
need also revert the commit r13-4686-g095a13eda2caf6.
(r13-4686 mentioned IPA-SRA detects whether parameters could be removed,
obviously it doesn't work well now if constants are not propagated before
IPA-SRA, it seems that the IPA-SRA only remove locally_unused parameters but
'm' is not locally used and the constants from caller are not visible in
IPA-SRA?)
[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351 --- Comment #2 from Andrew Pinski --- I noticed that with the C++ front-end early inline inlines f into main but with the C front-end it does not ...
[Bug tree-optimization/108351] [13 Regression] Dead Code Elimination Regression at -O3 since r13-4240-gfeeb0d68f1c708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351 Martin Liška changed: What|Removed |Added Summary|[13 Regression] Dead Code |[13 Regression] Dead Code |Elimination Regression at |Elimination Regression at |-O3 (trunk vs. 12.2.0) |-O3 since ||r13-4240-gfeeb0d68f1c708 Last reconfirmed||2023-01-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Thanks for the report. Please use the title as I've just modified and if possible, CC people who are authors of such a revision.
