On Mon, Nov 1, 2021 at 4:18 PM Jeff Law via Gcc <gcc@gcc.gnu.org> wrote: > > > > On 10/31/2021 6:12 AM, Aldy Hernandez wrote: > > After Jeff's explanation of the symbiosis between jump threading and > > the uninit pass, I'm beginning to see that (almost) every > > Wuninitialized warning is cause for reflection. It usually hides a > > missing jump thread. I investigated one such false positive > > (uninit-pred-7_a.c) and indeed, there's a missing thread. The > > question is what to do about it. > > > > This seemingly simple test is now regressing as can be seen by the > > xfail I added. > This looks amazingly familiar. You might want to look at this old thread: > > https://gcc.gnu.org/pipermail/gcc-patches/2017-May/474229.html > > > What happened was that threading did a better job, but in the process > the shape of the CFG changed in ways that made it harder for the > predicate analysis pass to prune paths. Richi & I never reached any > kind of conclusion on that patch, so it's never been applied.
Now there's also rangers relation oracle (not sure if that's even moderately powerful enough to cobble up predicates of two points in the CFG and relate them) and Martin(?) has split out the predicate analysis bits from uninit analysis. My stance is still that the machinery needs generalization. > Remember, that the whole point behind the predicate analysis pass is to > deal with infeasible paths that may be the in the CFG, including cases > where the threaders may have found a jump thread, but not optimized it > due to code size considerations. > > So one of the first things I'd do is look at the dumps prior to your > changes and see if the uninitialized use was still in the IL in > the.uninit dump, but was analyzed as properly guarded by predicate analysis. > > > > > What happens is that we now thread far more than before, causing the > > distance from definition to use to expand. The threading candidate > > that would make the Wuninitialized go away is there, and the backward > > threader can see it, but it refuses to thread it because the number of > > statements would be too large. > Right. > > > > > This is interesting because it means threading is causing larger IL > > that in turn keeps us from threading some unreachable paths later on > > because the paths are too large. > Yes. This is not unexpected. Jump threading reduces dynamic > conditional jumps and statements executed, but often at the expense of > increasing code size, much like PRE. Jump threading also can create > scenarios that can't be handled by the predicate analysis pass. > > The other thing to review is whether or not you're accounting for > statements that are going to be removed as a result of jump threading. > I had Alex implement that a few years back for the forward threader. > Essentially statements which exist merely to compute the conditional we > thread are going to be removed and we need not worry about the cost of > copying them which allowed us to thread many cases we had missed before > without increasing codesize. Yeah, and code size is important so simply upping the limit isn't the way to go since there's usually zero chance of a reverse transform later. > Anyway, those are the research areas to look at first, then we'll figure > out what the next steps are. > > JEff >
