https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #26 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- I think there's something fundamentally wrong in the *backwards* threader that causes us to blow up, even without fully resolving conditions with a global ranger. I tried running at -O1 and -fenable-tree-thread1. This basically adds just one non fully-resolving) backwards threader instance (i.e. not -fenable-tree-threadfull1, which is what we do at -O2). This helps analyze the problem with the backwards threader, bringing down the test arena from hours to less than 30 minutes: With -O1 -fenable-tree-thread1 (no threadfull): dominator optimization : 127.76 ( 7%) 0.57 ( 7%) 128.58 ( 7%) 236M ( 9%) backwards jump threading :1375.45 ( 79%) 1.81 ( 22%)1382.33 ( 79%) 519M ( 20%) TOTAL :1733.30 8.16 1747.35 2636M What's curious is that adding just this one non-resolving backward threader instance causes us to go from 370 seconds to 1733 seconds. That's a full 20 minutes for one backward threader pass. Richi mentioned that the handcuffs he added weren't being triggered in the backwards threader because ranger was going outside the path, but -fenable-tree-thread1 adds a light-weight threading pass that shouldn't use anything but gori (*). So, either we're doing something stupid in path discovery, or we're looking outside the path, even with a non-resolving threader. Something definitely smells bad. (*) Well, technically we use the global ranger to look at relations. Andrew, would looking at relations cause us to look outside of the given path?
