This is an archive of the discontinued LLVM Phabricator instance.

[ValueTracking] do not overwrite analysis results already computed
ClosedPublic

Authored by jingyue on Jun 5 2015, 12:44 PM.

Details

Summary

ValueTracking used to overwrite the analysis results computed from
assumes and dominating conditions. This patch fixes this issue.

Diff Detail

Event Timeline

jingyue updated this revision to Diff 27219.Jun 5 2015, 12:44 PM
jingyue retitled this revision from to [ValueTracking] do not overwrite analysis results already computed.
jingyue updated this object.
jingyue edited the test plan for this revision. (Show Details)
jingyue added a reviewer: hfinkel.
jingyue added a subscriber: Unknown Object (MLST).
majnemer edited edge metadata.Jun 10 2015, 5:49 PM

This change is quite large even if it is mostly mechanical. I don't understand how your change is connected to @llvm.assume.

jingyue updated this revision to Diff 27486.Jun 10 2015, 11:03 PM
jingyue edited edge metadata.

How about this patch? It is equivalent to the old patch but requires much less
source code modification.

The old patch writes the known bits computed from arithmetics (the big switch
starting from around L1080) to KnownZero1/2 and KnownOne1/2 locally, and updates
KnownZero and KnownOne afterwards.

The new patch saves KnownOne and KnownZero before the switch, and later merges
the saved results with the known bits computed from arithmetics.

I am fine with either approach. I slightly prefer the first one because
KnownOne and KnownZero consistently holds everything ValueTracking knows so
far. But the second approach requires less source code change.

How about this patch? It is equivalent to the old patch but requires much less
source code modification.

The old patch writes the known bits computed from arithmetics (the big switch
starting from around L1080) to KnownZero1/2 and KnownOne1/2 locally, and updates
KnownZero and KnownOne afterwards.

The new patch saves KnownOne and KnownZero before the switch, and later merges
the saved results with the known bits computed from arithmetics.

I am fine with either approach. I slightly prefer the first one because
KnownOne and KnownZero consistently holds everything ValueTracking knows so
far. But the second approach requires less source code change.

OK, so the issue is that computeKnownBitsFromAssume and computeKnownBitsFromDominatingCondition compute a result which is clobbered by the subsequent calls to computeKnownBits on the value operands?

It seems to me that computeKnownBitsFromAssume and computeKnownBitsFromDominatingCondition strictly refines their input. Could we just call them on line 1530?

computeKnonwBitsFromAssume only refines their inputs, but computeKnownBitsFromDominatingCondition calls computeKnownBitsFromTrueCondition which may clobber the inputs at http://llvm.org/docs/doxygen/html/ValueTracking_8cpp_source.html#l00555. That is the only place I found that may clobber KnownZero/KnownOne in these two functions, so if I remove the clobbering in computeKnownBitsFromTrueCondition, I agree I can call them at Line 1530.

However, it sounds weird that computeKnownBits may clobber inputs but some (if not all) computeKnownBitsXXX functions don't. Ideally, none of them should clobber inputs, right?

jingyue updated this revision to Diff 27652.Jun 14 2015, 9:47 PM

change the order of computeKnownBitsFrom* calls

  1. extract the code that computes known bits from an operator into

computeKnownBitsFromOperator.

  1. call computeKnownBitsFromAssume and

computeKnownBitsFromDominatingConditions after
computeKnownBitsFromOperator so that computeKnownBitsFromOperator
doesn't clobber the results computed by the other two.

  1. add dom-cond.ll to verify computeKnownBitsFromOperator does not

clobber the results computed by computeKnownBitsFromDominatingConditions.

jingyue updated this revision to Diff 27653.Jun 14 2015, 9:53 PM

misdeleted some lines in the previous patch

majnemer accepted this revision.Jun 14 2015, 10:39 PM
majnemer edited edge metadata.

LGTM, thanks!

This revision is now accepted and ready to land.Jun 14 2015, 10:39 PM
jingyue closed this revision.Jun 14 2015, 10:50 PM