On Mon, Nov 7, 2011 at 5:07 PM, Jeff Law <l...@redhat.com> wrote:
> -----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).
Heh, indeed, that as well. I suppose every pass that handles
unexecutable edges in some way might benefit from this. Like for
if (i)
j_1 = 1;
else
{
j_2 = 2;
*0 = ...;
}
j_3 = PHI <j_1, j_2>
we could CCP j_1 = 1 to j_3 ...
Even without actually removing the edge and the trapping stmt.
For DCE the most interesting part would be to end the block at
the point of the trap - thus - replace the store with a __builtin_trap ()
which then trivially makes all code w/o side-effects on the path
dead.
Richard.
>
>
>
> 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-----
>
