This is an archive of the discontinued LLVM Phabricator instance.

[OpaquePtr] Allow globals with opaque pointer value type
ClosedPublic

Authored by nikic on Jun 25 2021, 2:29 AM.

Details

Reviewers
aeubanks
Group Reviewers
Restricted Project
Commits
rG1e6303e60ca5: [OpaquePtr] Allow globals with opaque pointer value type
Summary

Do this by making opaque pointers a valid pointer element type, for which we implicitly create an opaque pointer (moving the logic from getPointerTo into PointerType::get).

We'll never create something like a "pointer to opaque pointer", but accept it in the API, because a lot of code reasonably assumes that you can create a pointer to pointer type.

Diff Detail

Event Timeline

nikic created this revision.Jun 25 2021, 2:29 AM
nikic requested review of this revision.Jun 25 2021, 2:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2021, 2:30 AM
aeubanks accepted this revision.Jun 25 2021, 8:52 AM
aeubanks added a subscriber: aeubanks.

lgtm, though invalid-opaque-ptr.ll is failing and should probably be deleted

This revision is now accepted and ready to land.Jun 25 2021, 8:52 AM
This revision was landed with ongoing or failed builds.Jun 25 2021, 9:29 AM
This revision was automatically updated to reflect the committed changes.

Do this by making opaque pointers a valid pointer element type, for which we implicitly create an opaque pointer (moving the logic from getPointerTo into PointerType::get).

Is there a way to test this? Maybe with something like this?

@g = global ptr null

lgtm, though invalid-opaque-ptr.ll is failing and should probably be deleted

I don't understand why the testcase was deleted. It seems to indicate a hole in the verifier. Isn't this still invalid IR?

define void @f(ptr %a) {
    %b = bitcast ptr %a to ptr*
    ret void
}

Do this by making opaque pointers a valid pointer element type, for which we implicitly create an opaque pointer (moving the logic from getPointerTo into PointerType::get).

Is there a way to test this? Maybe with something like this?

(Ignore that first comment — somehow I missed the chnage to opaque-ptr.ll! Still interested in a verifier change for the invalid IR though...)

dexonsmith added a comment.EditedJun 25 2021, 11:27 AM

lgtm, though invalid-opaque-ptr.ll is failing and should probably be deleted

I don't understand why the testcase was deleted. It seems to indicate a hole in the verifier. Isn't this still invalid IR?

define void @f(ptr %a) {
    %b = bitcast ptr %a to ptr*
    ret void
}

Ah, I see -- the parsed IR will be correct do to the change to PointerType::get. So this isn't a verifier bug, it's a parser bug.

Seems like you just need to update:

// Type ::= Type '*'
case lltok::star:
  if (Result->isLabelTy())
    return tokError("basic block pointers are invalid");
  if (Result->isVoidTy())
    return tokError("pointers to void are invalid - use i8* instead");
  if (!PointerType::isValidElementType(Result))
    return tokError("pointer to this type is invalid");

to have:

if (Result->isOpaquePointerTy())
  return tokError("pointer to opaque pointer is invalid");

before the the call to isValidElementType.

You'd need to update the logic in the similar case below for lltok::kw_addrspace as well.

llvm/lib/IR/Type.cpp