https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> --- I never explored the idea, but Bodik has a discussion of recording infeasible paths in the CFG which would seem to address this issue. He was using the concept in the context of coverage analysis -- the idea being if you were supposed to be providing 100% coverage, then you have to know if there are paths that simply can't be executed at runtime that were left in the CFG. Anyway... If we find a thread, but fail to optimize it because of the cost -- we record data in the CFG on the path infeasibility. The uninit pass (or any pass for that matter) could then query that data and realize the path isn't feasible and suppress the warning in that case. My concern with Bodik's approach is the marking and keeping those markings up-to-date through the pipeline. So that's one approach. The other is to introduce the solver into the predicate analysis pass which starts to touch on other ideas I've had. Namely that thread discovery and predicate analysis are closely related. ie, we could be using predicate analysis to discover more threading opportunities and we could be using the path solver to prune out infeasible paths for the uninit (and other) passes by integrating path solving into predicate analysis. What you've done is the first step in this direction.
