-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > I also wonder if instead of a new pass control-dependent DCE can be > taught of this? It could. I'm not sure it really buys us anything except maybe being able to reuse the pdom & control-dependency analysis. It actually more naturally belongs in cprop because it's cprop that exposes NULL pointers in useful ways (in memory dereferences and as PHI args). At least I presume that this code removal can > expose DCE opportunities and DCE can expose these code removal > opportunities? In theory, yes. However, because we find & remove the edge upon which the memory reference is control dependent upon, what we really expose is unreachable code. Hence the CFG cleanup pass. Secondary effects I've witnessed are more block merging exposed due to CFG simplifications and further const/copy propagation exposed by edge removal at the point where unexecutable & executable paths meet. It's not hard to imagine how this could lead to additional DCE opportunities and other optimizations, I just haven't looked for them or noticed them. The valgrind results are a good indication that we're picking up good secondary optimizations. I don't think DCE will often lead to new opportunities for this code, it could happen, but I'd expect it to be the exception rather than the norm. FWIW, the location of the pass right now sits just after DOM1 so a goodly amount of constant propagation is already done, but we still get a chance to pick up the secondary optimization opportunities in DOM2. The pass also sits between two DCE passes, so if DCE is exposing opportunities for this pass, we get them and if this pass is exposing opportunities for DCE, we get them too :-) > > Did you consider simplifying the code by simply relying on > points-to analysis? Thus for the dereferenced SSA name check > > pi = SSA_NAME_PTR_INFO (name); if (pi && pt_solution_empty_p > (&pi->pt)) Nope. I guess it could be added, though it's often important to know the origin of the NULL pointer. p5 = PHI (p4 (1), 0 (0)) ... if (cond) goto X else goto Y X: foo (P5) goto Z Y: *p5 = <value> Z: Analysis will mark P5 is being potentially NULL, but it would incorrect to remove the edge corresponding to the NULL PHI arguement as traversing that edge does not guarantee we will dereference the NULL pointer. The most interesting answer from PTA would be things like this pointer must be NULL, but if that's true, then it should have been propagated to the use sites already. > ... > > ? I once implemented a warning to warn about such derefrences, but > it (of course ...) triggers for all the unexecutable code paths... Yup. The one I've got here looks like a traditional propagation engine. There's knobs on it to tweak how it handles loads from memory, call return values, etc. Utilizing PTA would certainly help. I'll put that on the TODO list. I would have liked to have it polished in time for GCC 4.7, but other events got in the way. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuAJbAAoJEBRtltQi2kC7cA4H/jrPusXwvf0ECDh5MP/hNcna R+zHWQPVOsPsyZkJCEuGqBkLT0+2ar0fS0uiqcXrZelY+TqAw0geg5t60w4lHF9p 9ERDqsBExVZW0X2VdnTZrYyfyB/fOc9xIizp/KxDWV33i7CwDFOyYR7QwXZnAMcp 7lpdzzxRbFaq05kj9K2aFtt8X/N7+Gn7dsI7kTLexmU2T+rXEF8P/HEqNefz70tV t23W9V81cbZDP9g9LhJzrMfQrylI/lSk+Nve10aBal0EVPi5IzWAvxfL5uxD3G4l sxOuH9bD7dNGDdJI1JnFxz56Z4DNI/0ARHM/RsZDbcAFUm8FG/DIzitBPslFegY= =24NO -----END PGP SIGNATURE-----
