This is an archive of the discontinued LLVM Phabricator instance.

Refactor computeKnownBits alignment handling code
ClosedPublic

Authored by apilipenko on Sep 18 2015, 6:01 AM.

Details

Summary

This is a preparatory refactoring for using new alignment attributes/metadata (D12844, D12853) in computeKnownBits.

Diff Detail

Repository
rL LLVM

Event Timeline

apilipenko updated this revision to Diff 35076.Sep 18 2015, 6:01 AM
apilipenko retitled this revision from to Refactor computeKnownBits alignment handling code.
apilipenko updated this object.
apilipenko added reviewers: hfinkel, reames.
apilipenko added a subscriber: llvm-commits.
reames added inline comments.Sep 21 2015, 8:00 AM
lib/Analysis/ValueTracking.cpp
1488 ↗(On Diff #35076)

I'm not sure that removing these returns is actually equivalent. Does computeKnownBits guarantee to preserve any known bits on entry? (I don't think so?) If not, then letting these flow down into the generic code may loose information.

apilipenko added inline comments.Sep 22 2015, 8:22 AM
lib/Analysis/ValueTracking.cpp
1488 ↗(On Diff #35076)

In all existing code paths computeKnownBits starts with cleared bits on both KnownZero and KnownOne. In my patch I just made it explicit by moving the lines which clear both bit sets before the code which handles aligned values. See line 1466.

reames added inline comments.Sep 22 2015, 4:01 PM
lib/Analysis/ValueTracking.cpp
1488 ↗(On Diff #35076)

I wasn't commenting on the movement of the clearing. I was commenting on the removal of the return.

hfinkel added inline comments.Sep 23 2015, 1:47 AM
lib/Analysis/ValueTracking.cpp
1488 ↗(On Diff #35076)

I think this is okay because the functions below that clear known bits are only called if V is a GlobalAlias or an Operator, neither of which is true if V is known to be a GlobalObject (or an Argument).

I agree, however, that the relevant logic here is becoming increasingly unclear. How about we move this alignment logic below the computeKnownBitsFromOperator call, so that it is clear (at least based on existing commentary) that we only ever refine this information? This also has the benefit that we can use an 'else if' and elide some unnecessary dyn_cast checks.

reames added inline comments.Sep 23 2015, 12:17 PM
lib/Analysis/ValueTracking.cpp
1488 ↗(On Diff #35076)

Hal, I follow your logic for why the current patch is correct. Moving the flow as you suggest would be one option. Adding a couple of assertions that the sets are empty at the point we call each routine would be another. Adding explicit merge code to future proof this code would be a a third. I'd be fine with any of the options. I'd mildly lean towards the explicit merging code since I think that supports the direction Artur wants to take this code (right?).

Introduce new function getAlignemnt(Value*). I'm going to use this function from isAligned as well.

Alignment related code in computeKnownBits is moved below the computeKnownBitsFromOperator call.

reames edited edge metadata.Sep 29 2015, 8:07 AM

Much, much clearer. LGTM

lib/Analysis/ValueTracking.cpp
1516 ↗(On Diff #35745)

I might put this inside a check for pointer type, but it's already handled by the called code and would only be a minor improvement on a much larger improvement.

This revision was automatically updated to reflect the committed changes.