[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2 since r11-4987-g602c6cfc79ce4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Jeffrey A. Law --- Tracking in 113907 as that one has more detail about the ICF vs Ranges issue, possible short and longer term solutions, etc. *** This bug has been marked as a duplicate of bug 113907 ***
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2 since r11-4987-g602c6cfc79ce4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 --- Comment #9 from Richard Biener --- (In reply to Jan Hubicka from comment #8) > > Honza - ICF seems to fixup points-to sets when merging variables, so there > > should be a way to kill off flow-sensitive info inside prevailing bodies > > as well. But would that happen before inlining the body? Can you work > > on that? I think comparing ranges would weaken ICF unnecessarily? > > AFAIK ICF does no changes to winning function body. It basically relies > on the fact that early optimizations are local and thus arrive to same > solutions for most of metadata. So only really easy fix is to make it > match value ranges, too. I will check how much that fire in practice - > I can only think of split funtions to diverge, which is probably not > that bad in practice. But is it possible to add a local transform stage and would that also affect which body we inline? But yes, inlining the original body would be so much better ...
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2 since r11-4987-g602c6cfc79ce4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 --- Comment #8 from Jan Hubicka --- > Honza - ICF seems to fixup points-to sets when merging variables, so there > should be a way to kill off flow-sensitive info inside prevailing bodies > as well. But would that happen before inlining the body? Can you work > on that? I think comparing ranges would weaken ICF unnecessarily? AFAIK ICF does no changes to winning function body. It basically relies on the fact that early optimizations are local and thus arrive to same solutions for most of metadata. So only really easy fix is to make it match value ranges, too. I will check how much that fire in practice - I can only think of split funtions to diverge, which is probably not that bad in practice. IPA-prop and IPA-PTA is only done after ICF. We indeed discussed clearing possibility of merging alias sets which is relatively important in practice (increasing TBAA precision on LTO slowly degraded ICF effectivity significantly), but got into glory details of inventing representation which would make inliner to pick right body (without alias sets cleared). This was never made to fly (Martin got scared by the details and I got it on my ever overflowing TODO list). Honza
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2 since r11-4987-g602c6cfc79ce4a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 Sam James changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13/14 regression] |Regular for Loop results in |Regular for Loop results in |Endless Loop with -O2 |Endless Loop with -O2 since ||r11-4987-g602c6cfc79ce4a --- Comment #7 from Sam James --- (In reply to Andrew Pinski from comment #4) > (In reply to Sam James from comment #3) > > I will try bisect. > > Most likely r11-5094-gafa6adbd6c83ee or r11-4987-g602c6cfc79ce4a or > r11-4986-ga1fdc16da34118 . r11-4987-g602c6cfc79ce4a is the first bad commit commit r11-4987-g602c6cfc79ce4a Author: Jan Hubicka Date: Fri Nov 13 15:58:41 2020 +0100 Improve handling of memory operands in ipa-icf 2/4
