This is an archive of the discontinued LLVM Phabricator instance.

[OpaquePtr] Track pointee types in Clang
AbandonedPublic

Authored by aeubanks on Jun 1 2021, 9:04 AM.

Details

Reviewers
dblaikie
rsmith
Summary

With pointee types going away in llvm::PointerType, the frontend needs
to keep track of pointee types.

Add a PointeeType to Address and LValue.

Diff Detail

Event Timeline

aeubanks created this revision.Jun 1 2021, 9:04 AM
aeubanks published this revision for review.Jun 1 2021, 9:04 AM
aeubanks added reviewers: dblaikie, rsmith.

This is definitely WIP, but I'd like to make sure that this is the right direction before continuing. And are there any other obvious places that also require this?

Herald added a project: Restricted Project. · View Herald TranscriptJun 1 2021, 9:06 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

The changes look like the right direction to me - though I don't know/couldn't confirm whether more changes will be needed in other places.

clang/lib/CodeGen/Address.h
29–30

At some point will this include an assertion that 'pointer' isn't a PointerType? I guess some uses of PointerTyped values won't need to know their pointee type?

(or are all values in Address PointerTyped? (owing to them being "addresses"))?

56–57

hey, someone wrote a handy comment here - could possibly delete this comment now that that reality has come to pass

clang/lib/CodeGen/CGExpr.cpp
159

Could potentially pull these sort of changes out as a separate patch/commit without pre-commit review, since they rely on the existing API.

clang/lib/CodeGen/CGValue.h
230–231

Maybe this could use some assertions added to check the PointeeType is correct?

nikic added a subscriber: nikic.Jul 7 2021, 3:04 PM

Maybe send a mail to cfe-dev to solicit some help with the opaque pointer migration on the clang side?

clang/lib/CodeGen/Address.h
29–30

Based on the unconditional cast in getType(), I'd assume that addresses are always pointer typed.

craig.topper added inline comments.
clang/lib/CodeGen/Address.h
31

Is PointeeType expected to be non-null when pointer is non-null?

58

Should this assert isValid() since it no longer goes through getType() and getPointer() which would have asserted previously?

erichkeane added inline comments.
clang/lib/CodeGen/Address.h
26

I think this will still end up being a problem when we try to look into the type for multi-dimension pointers. Should we have this just store the QualType of the value instead, so we can unpack it later? If we ever needed the llvm::Type of the Pointee, a convertTypeForMem is all that is standing in our way.

jyknight added inline comments.
clang/lib/CodeGen/Address.h
26

Do we do that? I didn't think Address was used that way.

29–30

This constructor seems odd. We shouldn't ever construct Address with a non-null pointer and a null PointeeType, should we?

31

That would be my expectation.

58

+1.

clang/lib/CodeGen/CGValue.h
230–231

I think Initialize should be modified to take Addr instead of Alignment, and move

R.V = Addr.getPointer();
R.PointeeType = Addr.getElementType();

into this function, from all the callers.

If that's done, I don't think a separate assert is useful.

aeubanks abandoned this revision.Feb 18 2022, 2:48 PM