This is an archive of the discontinued LLVM Phabricator instance.

[OpaquePtr][LoopAccessAnalysis] Support opaque pointers

Authored by aeubanks on Feb 4 2022, 5:15 PM.


Group Reviewers
Restricted Project
rGff31020ee651: [OpaquePtr][LoopAccessAnalysis] Support opaque pointers

Previously we relied on the pointee type to determine what type we need
to do runtime pointer access checks.

With opaque pointers, we can access a pointer with more than one type,
so now we keep track of all the types we're accessing a pointer's
memory with.

Also some other minor getPointerElementType() removals.

Diff Detail

Event Timeline

aeubanks created this revision.Feb 4 2022, 5:15 PM
aeubanks requested review of this revision.Feb 4 2022, 5:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 5:15 PM
aeubanks added reviewers: fhahn, Restricted Project.Feb 4 2022, 5:17 PM
nikic added a subscriber: nikic.Feb 5 2022, 12:38 AM

Looks correct to me, but it would be good to check that the result is actually correct. Maybe add an opaque pointers version of an existing test? depend_diff_types.ll looks like a good candidate, because it deals with bitcasted accesses.

aeubanks updated this revision to Diff 406669.Feb 7 2022, 6:22 PM

fix all of LAA, needed to get the test working with opaque pointers

aeubanks retitled this revision from [OpaquePtr][LAA] Don't use getPointerElementType() to [OpaquePtr][LoopAccessAnalysis] Support opaque pointers.Feb 7 2022, 6:23 PM
aeubanks edited the summary of this revision. (Show Details)
nikic accepted this revision.Feb 8 2022, 2:23 AM

Looks reasonable to me. I think ideally this code would be working based on the largest store size used in any access or something like that, but I think your current implementation matches what this code currently does for non-opaque pointers in spirit.

37 ↗(On Diff #406669)

These ptr-to-ptr bitcasts should be dropped, to make sure that we actually test the case where the same Value * is accessed with different types. Right now, this artificially creates separate pointer values.

This revision is now accepted and ready to land.Feb 8 2022, 2:23 AM
fhahn added inline comments.Feb 8 2022, 3:00 AM

I think we need at least test cases where there are actually more than on AccessTy. This seems not be be covered by the existing tests at the moment

aeubanks updated this revision to Diff 406894.Feb 8 2022, 10:53 AM

update test to not have bitcasts
required updating LoopAccessInfo::analyzeLoop() to take AccessTy into account alongside the pointer value

nikic accepted this revision.Feb 9 2022, 1:27 AM
This revision was automatically updated to reflect the committed changes.
fhahn added inline comments.Feb 9 2022, 9:34 AM

Did you check if there's a test case with multiple access types that covers this code? It seems like this is still missing. One way to test this would be to have a loop-versioning test. IIUC multiple checks need to be generated with the correct access types now.

aeubanks added inline comments.Feb 9 2022, 11:27 AM

Oh sorry I got this part confused with the part above. I'm not super familiar with this so any help with constructing a test case would be appreciated, but I'll try to come up with one.