On 11/13/2017 06:21 PM, Martin Sebor wrote: > I have a different concern with the general idea of moving these > kinds of warnings into passes of their own. It would unavoidably > result in duplicating some code from the optimization passes (at > a minimum, the GIMPLE traversal, but likely more than that). It > would also require pretty tight coupling between the warning pass > and the optimization passes as the latter can defeat the work of > the former (as happens in this case). But most significantly, > the separation isn't feasible in cases where the optimization > pass computes and maintains non-trivial internal state (like, > say, tree-object-size or tree-ssa-strlen). Something like object-size, string lengths, value data, etc should be independent analysis modules. You then build an optimizer on top of the module and/or a warning pass on top of the module. The optimizer and warning pass might in fact share analysis and just do different things with the underlying data produced.
It's not perfect and we're not likely to ever be perfect, but it's a hell of a lot better than what we're doing now. Yes there'll be phase ordering problems, problems with other passes hiding or exposing questionable code, possibly duplication between the optimization client and warning client, etc, etc. We have to look at each problem and decide how best to proceed. I do think that the frameworks we build should have mechanisms to allow transformation of code that is clearly wrong and exhibits undefined behavior. > > That said, it would make perfect sense to me to have the warning > code live in separate files from the optimization code, and keep > the separation of concerns and responsibilities crisp and well > defined by their APIs. Where that's feasible it seems reasonable to me. I'm obviously biased based on recent experiences within VRP which has grown over time into a horrid mess my forays into tree-ssa-uninit.c which has a damn cool little predicate analysis engine just waiting for someone extract and re-use. Jeff
