This is an archive of the discontinued LLVM Phabricator instance.

Fix handling of signWrappedSets in access relations
ClosedPublic

Authored by maxf on May 5 2017, 1:32 AM.

Details

Summary

Since r294891, in MemoryAccess::computeBoundsOnAccessRelation(), we skip
manually bounding the access relation in case the parameter of the load
instruction is already a wrapped set. Later on we assume that the lower
bound on the set is always smaller or equal to the upper bound on the
set. Bug 32715 manages to construct a sign wrapped set, in which case
the assertion does not necessarily hold. Fix this by handling a sign
wrapped set similar to a normal wrapped set, that is skipping the
computation.

Diff Detail

Repository
rL LLVM

Event Timeline

maxf created this revision.May 5 2017, 1:32 AM
This revision was automatically updated to reflect the committed changes.
grosser edited edge metadata.May 5 2017, 6:37 AM

Hi Matthias,

this patch looks very good. I had three minor remarks (see below). As they were very minor, I addressed them directly and immediately committed your patch. These changes are available from r302231.

test/ScopInfo/sign_wrapped_set.ll
7 ↗(On Diff #97916)

I would also check the memory access functions here.

20 ↗(On Diff #97916)

Trailing whitespaces.

24 ↗(On Diff #97916)

Trailing whitespaces.

Hi,

This is probably a late comment,

Why are we using "Range.isWrappedSet() | Range.isSignWrappedSet(" instead of the shorthand "Range.isWrappedSet() || Range.isSignWrappedSet("

I do not see a specific reason why we prefer "|" over "||". Just now saw the difference. Maxililian, what is your opinion here?

maxf added a comment.May 18 2017, 2:20 AM

Hi everyone,

That would have been an oversight on my part, there is no specific reason. Shall I reopen?

It is not a big problem really but it just gives the impression that you always want the "Range.isSignWrappedSet" to be executed which is confusing since its an accessor const function anyway.