[IR] Add a target extension type to LLVM.

[jcranmer-intel]

Summary

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizations. This patch doesn't add any uses of these types by an existing
backend, it only provides basic infrastructure such that these types would work
correctly.

RFC: https://discourse.llvm.org/t/rfc-adding-opaque-types-to-llvm-ir/65326

[arichardson]

llvm/include/llvm/IR/DataLayout.h

678

Why is the size hardcoded to an as0 pointer? Wouldn't it make more sense to e.g. have the first type parameter define the underlying size?

[nikic]

The implementation looks reasonable. In terms of design, I basically have the same concern as everyone else: Hardcoding the layout to ptr seems pretty dubious. The suggestion to specify the layout type as a parameter seems pretty sensible.

Less importantly, I wonder whether the integer parameters should be represented as APInt rather than 32-bit ints.

llvm/docs/BitCodeFormat.rst

1342

nit: You need moar ^

llvm/docs/LangRef.rst

3609

Something that's a bit confusing is that we have both "opaque type" and "opaque structure type", the former spelled %x = type opaque, the latter spelled opaque("x"). This seems rather unfortunate.

I think a viable way forward would be to keep the old notion of opaque types, but move away from the "opaque" terminology for them. Effectively, an opaque struct type is just an identified struct type with zero members.

3634

There should be a mention of the type size and alignment somewhere.

llvm/include/llvm/IR/DerivedTypes.h

758

You can likely = None these and don't need a separate overload.

llvm/lib/IR/Constants.cpp

1092

This looks pretty dubious. We probably shouldn't be modelling opaque types using ConstantAggregateZero, as it is not an aggregate type.

Is zeroinitializer support actually required?

llvm/lib/IR/Function.cpp

857

This must be unique per type, so you need to include all the nested information as well. You can add tests using the ssa.copy intrinsic.

llvm/lib/IR/LLVMContextImpl.h

213

return Name == that.Name && TypeParams == that.TypeParams && IntParams == that.IntParams?

llvm/lib/Transforms/Scalar/SROA.cpp

1718

Does CastInst::isBitCastable need an adjustment?

[nhaehnle]

llvm/docs/LangRef.rst

3609

Thinking about this a bit more, I think it would be good to move away from the "opaque" naming entirely and instead call these new types something like an "extension" type or a "generic" type.

It's a bit of a philosophical point, but the types being added here aren't necessarily opaque in a universal sense. They are opaque to core IR instructions, but they are not opaque to e.g. intrinsics that are added specifically for working with them.

(And the same is true for the "opaque" structs as well. "Identified struct type with zero members" is what they are, so why not just run with it.)

[jcranmer-intel]

Sorry for the delay in responding to comments, I've been trying to get the subsequent changes that use for SPIR-V polished.

In D135202#3836252, @nikic wrote:

The implementation looks reasonable. In terms of design, I basically have the same concern as everyone else: Hardcoding the layout to ptr seems pretty dubious. The suggestion to specify the layout type as a parameter seems pretty sensible.

As pointed out, specifying an underlying type isn't necessarily feasible. But I could add optional type properties that would include size and alignment to start with (and have those default to sizeof(ptr) and size, respectively)--how does that sound?

Less importantly, I wonder whether the integer parameters should be represented as APInt rather than 32-bit ints.

I've considered this as well. But I strongly doubt that there's a need to go up that high at this point, and nothing in the current design blocks revisiting this should we need to in the future (if my understanding of bitcode is correct), so I'm inclined to keep it as-is for now.

llvm/docs/LangRef.rst

3609

"Opaque types" has some precedent (it's what the SPIR-V specification calls these types), but I suspect that terminology derives from opaque types, given the role of LLVM in SPIR's history.

%x = type opaque and opaque("x") being similar is indeed very unfortunate. For a while, I've been thinking that opaque pointers themselves make opaque structs obsolete--there's very little you can do on them once a pointer to them is indistinguishable from any other pointer--which would help remove the confusion.

As far a better name, I'm having a tough time coming up with a short name. Something with "target" in it I think captures the semantics well, but "target type" feels insufficient, and "target-extension type" or "target-specified type" a little wordy. But moving to a target("spirv.Image", void, 2, 0, 0, 0, 0, 0, 1) syntax (to use an actual use of this for SPIR-V) I think reads slightly better than using opaque.

3634

Noted, will fix.

llvm/lib/IR/Constants.cpp

1092

Yes, for at least some of the types. (https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpConstantNull lists the opaque types for which something like null exists).

I agree that ConstantAggregateZero is somewhat dubious as a class, but it seemed more fitting than any other class, not least of which being the fact that it causes zeroinitializer to work without any extra effort.

I'm open to suggestions as to what to name a new zeroinitializer class for opaque pointers--I don't have any great names off my head.

llvm/lib/IR/Function.cpp

857

Good catch--I had originally coded this up without any type/integer parameters, and missed the need to change this location as well. Will fix!

llvm/lib/Transforms/Scalar/SROA.cpp

1718

It turns out not to need it--CastInst::isBitCastable returns false if Type::getPrimitiveSizeInBits returns 0 for either parameter, and Type::getPrimitiveSizeInBits returns 0 for opaque types.

(This made it easy to confirm when optimizations caused problems--they tried to create bitcast instructions with opaque types, and that failed.) I can add an extra check for safety.

[nhaehnle]

llvm/docs/LangRef.rst

3609

How about ext(...)? But target(...) is fine with me, too.

llvm/lib/IR/Constants.cpp

1092

Would an intrinsic that returns the null value work? Or are null initializers also allowed in global variables?

[nhaehnle]

Here's a random thought: what if the types are parameterized using metadata instead of ints?

[jcranmer-intel]

In D135202#3855371, @nhaehnle wrote:

Here's a random thought: what if the types are parameterized using metadata instead of ints?

My original thought was using ConstantInt, actually, and that should in principle be relatively easy to parse. Getting the integer value out of metadata is a pretty circuitous route, and if you want arbitrary-sized integers, ConstantInt or an APInt are much simpler routes.

One downside with ConstantInt is that it implies the *size* of the integer matters for distinguishing types (e.g., ext("a", i32 10) is not the same as ext("a", i64 10)). That makes APInt seem a better solution to me than ConstantInt, but I'm not entirely certain the extra flexibility over a bare unsigned is necessary--if it does turn out to be the case, upgrading unsigned to APInt could still be done without substantial changes to syntax or API.

llvm/lib/IR/Constants.cpp

1092

Global variable null initializers are I believe necessary.

[nikic]

In D135202#3843673, @jcranmer-intel wrote:

Sorry for the delay in responding to comments, I've been trying to get the subsequent changes that use for SPIR-V polished.

In D135202#3836252, @nikic wrote:

The implementation looks reasonable. In terms of design, I basically have the same concern as everyone else: Hardcoding the layout to ptr seems pretty dubious. The suggestion to specify the layout type as a parameter seems pretty sensible.

As pointed out, specifying an underlying type isn't necessarily feasible.

I couldn't find where this has been pointed out, could you please link me to it? I don't really get why it wouldn't be feasible, given that your current proposal effectively already does it, just with a hardcoded ptr type.

But I could add optional type properties that would include size and alignment to start with (and have those default to sizeof(ptr) and size, respectively)--how does that sound?

That would be fine as well, though probably harder to implement.

In D135202#3855371, @nhaehnle wrote:

Here's a random thought: what if the types are parameterized using metadata instead of ints?

I was originally going to suggest to parameterize them by Constants. But then I realized that this would add a cyclic dependency between values and types. Currently values only use types, but not the other way around. It's probably possible to support this, but it seems like a very large complication that's unlikely to be justified. The same concern holds for metadata (probably to an even larger degree).

[nhaehnle]

In D135202#3860361, @nikic wrote:

In D135202#3855371, @nhaehnle wrote:

Here's a random thought: what if the types are parameterized using metadata instead of ints?

I was originally going to suggest to parameterize them by Constants. But then I realized that this would add a cyclic dependency between values and types. Currently values only use types, but not the other way around. It's probably possible to support this, but it seems like a very large complication that's unlikely to be justified. The same concern holds for metadata (probably to an even larger degree).

Yeah, that's a fair point.

[jcranmer-intel]

Fix some of the nits.

This does not address the name concerns or size/align/underlying type concerns
yet.

[jcranmer-intel]

In D135202#3860361, @nikic wrote:

I couldn't find where this has been pointed out, could you please link me to it? I don't really get why it wouldn't be feasible, given that your current proposal effectively already does it, just with a hardcoded ptr type.

https://discourse.llvm.org/t/rfc-adding-opaque-types-to-llvm-ir/65326/10 was what I was thinking of, but looking back, it's not as thorough as I thought it was.

The broad issue with opaque types in general is that there's not necessarily an underlying type. For SPIR-V, it's the case that these types almost always [1] ultimately lower into a ptr (of some address space) or a i32 type (or i32-stored-as-a-ptr), so pretending that these types are ptr is a viable strategy--indeed, this is what the current SPIR-V target lowering does. I don't know @asb's WASM use case very well, but I imagine treating opaque types as a ptr in a trenchcoat would similarly ultimately work correctly.

Look past these use cases, however, and underlying types get murkier. It's true that I didn't account for these yet, but that was more a matter of punting on design decisions that didn't need addressing for this specific use case. If x86_mmx and x86_amx were implemented as opaque types [2], their underlying type is murkier--perhaps vectors of 64 bit and 8,192 bit respectively, but what vector element type would you pick for them? Some of the exotic hardware I've worked on (whose details are unfortunately not public) could find an opaque type useful, but those types can't find any underlying type that would be useful--something like opaque("hw", float) would mean "you can get a float from me", but treating it as a float in a trenchcoat would be absolutely catastrophic.

My biggest worry with trying to use underlying types is that it would encourage people to think of opaque types as "it's really just a T" when the entire point of opaque types is that it has to be treated differently from a T.

[1] Read as "this is the case in every backend I checked", which is admittedly a very far cry from "all of them". Although the chosen address space does vary between different targets, ptr addrspace(0) is sufficiently pessimistic for size/alignment information.
[2] I'm not proposing doing this, but they do provide some useful checks for what might be relevant.

But I could add optional type properties that would include size and alignment to start with (and have those default to sizeof(ptr) and size, respectively)--how does that sound?

That would be fine as well, though probably harder to implement.

Type properties are already something I've considered necessary anyways, and size/alignment is a very natural place to start; I didn't include them in this patch principally because the code I had didn't need them yet (as relying on the default being ptr was sufficient for my needs, although I now see that it caused more reviewer confusion than I anticipated).

[jcranmer-intel]

Major update.

The big change is the great renaming from "opaque type" to "target extension
type". There's still a few places that haven't had there name updated yet. Fixes
to documentation are still needed as well.

In addition, this creates a notion of type properties that is used to fix some
of the issues mentioned above. There is a major unresolved question in this
update as to where the logic to get the type properties of a target extension
type should be located. I see 4 options:

1. Specified during type creation.
2. Attach to the module akin to existing identified struct type logic.
3. Attach to DataLayout via the datalayout string or something similar.
4. Lookup table built-in to LLVM.

[Note that the current implementation, a static function in Type.cpp, is not any
of these options, but it is most similar to option 4, although I would replace
that with something tablegen-driven most likely, like existing Attributes.td.]

These options are laid out from most to least flexible. While I'm not entirely
happy with how option 4 requires modification to LLVM to effectively add new
target extension types, it would make it about as difficult to add a new type as
it would be to add a new attribute, which seems appropriate.

[nikic]

In D135202#3906261, @jcranmer-intel wrote:

In addition, this creates a notion of type properties that is used to fix some
of the issues mentioned above. There is a major unresolved question in this
update as to where the logic to get the type properties of a target extension
type should be located. I see 4 options:

1. Specified during type creation.
2. Attach to the module akin to existing identified struct type logic.
3. Attach to DataLayout via the datalayout string or something similar.
4. Lookup table built-in to LLVM.

[Note that the current implementation, a static function in Type.cpp, is not any
of these options, but it is most similar to option 4, although I would replace
that with something tablegen-driven most likely, like existing Attributes.td.]

These options are laid out from most to least flexible. While I'm not entirely
happy with how option 4 requires modification to LLVM to effectively add new
target extension types, it would make it about as difficult to add a new type as
it would be to add a new attribute, which seems appropriate.

A hard constraint here is that we need to be able to determine type layout from just the Type and DataLayout, so I don't think that anything involving the Module is possible.

TBH, I think your current approach of just hardcoding the type properties is fine. We can extend this to a more dynamic solution later if needed. It might make sense to compute the properties on construction though and store them in the type (which would then also be the entry-point to a more dynamic solution, by accepting these as arguments). I don't think we need TableGen for this either, as there's no need to generate multiple tables from one base data set.

llvm/include/llvm-c/Types.h

68 ↗

(On Diff #473023)

This doesn't look right...

llvm/include/llvm/IR/Type.h

277

Should this check whether the layout type is sized? (I.e., does it make sense to also support unsized target types?)

[jcranmer-intel]

Doc tweaks, name tweaks, add some verification code.

[jcranmer-intel]

Rebase on trunk.

[jcranmer-intel]

Friendly review ping?

[nikic]

llvm/lib/AsmParser/LLParser.cpp

2982

nit: Can drop explicit SmallVector sizes here.

llvm/lib/IR/Type.cpp

852

It looks like the HasZeroInit property exists, but is never actually checked anywhere? Should either drop it or check it.

855

Probably want to drop this one before landing, as it's part of a different RFC.

858

I'd probably go for defaulting to an unsized (and thus maximally limited) type. i1 seems like an odd choice.

[jcranmer-intel]

Address review comments.

[nikic]

LGTM

llvm/docs/LangRef.rst

3624

Possibly this should clarify that not all target extension types can have zeroinitializer.

llvm/test/Assembler/target-type-properties.ll

2 ↗

(On Diff #481733)

This is pretty weird, use split-file instead?

[jcranmer-intel]

Documentation and test tweaks.

[arsenm]

llvm/test/Assembler/target-type-properties.ll

13 ↗

(On Diff #482940)

Is empty string valid?

[aeubanks]

the comments and patch description are inconsistent about "opaque" vs "target extension", cleaning this up would be good for avoiding confusion in the future

[jcranmer-intel]

In D135202#3996159, @aeubanks wrote:

the comments and patch description are inconsistent about "opaque" vs "target extension", cleaning this up would be good for avoiding confusion in the future

I updated the git commit message locally, but it seems that Arcanist wasn't taking the changes into account here.

llvm/test/Assembler/target-type-properties.ll

13 ↗

(On Diff #482940)

Yes, it should be.

[jcranmer-intel]

Rebase to trunk, and add release notes.

[barannikov88]

Some pedantic nits.
"opaque" remains in some places.

llvm/docs/ReleaseNotes.rst

108 ↗

(On Diff #483996)

"target-specific types whose types" is confusing.
Do I read it wrong or did you mean something different? In any case this should be clarified.

llvm/include/llvm-c/Core.h

289

Nit: add comma

llvm/include/llvm/IR/Constants.h

867 ↗

(On Diff #483996)

Above comments are missing '.' in the end and this one ends with a colon.

llvm/lib/IR/Type.cpp

837

The struct should be in anonymous namespace.

[jcranmer-intel]

Address review comments (and clang-format issues).

[barannikov88]

llvm/docs/ReleaseNotes.rst

109 ↗

(On Diff #484057)

I hesitate to make comments about someone's English because my English is not so good.
The sentence still does not sound right to me, this part: "types ... are not introspectable by ... types"
Please ignore if everything is OK.

[jcranmer-intel]

Fix typo in release notes.

llvm/docs/ReleaseNotes.rst

109 ↗

(On Diff #484057)

The word was meant to be "optimizations", not "types". The casualties of writing too quickly. :-)

[barannikov88]

@jcranmer-intel
A new build warning:
llvm/lib/Target/Hexagon/HexagonTargetObjectFile.cpp:296:11: warning: enumeration value 'TargetExtTyID' not handled in switch [-Wswitch]

[jcranmer-intel]

In D135202#4008212, @barannikov88 wrote:

@jcranmer-intel
A new build warning:
llvm/lib/Target/Hexagon/HexagonTargetObjectFile.cpp:296:11: warning: enumeration value 'TargetExtTyID' not handled in switch [-Wswitch]

Fixed via https://reviews.llvm.org/rGaa34a9d108bd79eb0ac40979a7bdae4b19b1624d

[zixuan-wu]

llvm/lib/IR/Type.cpp

839

Can the LayoutType be struct type, or scalable vector type?

852

Is there anymore better code structure to separate target-specific code to get TargetTypeInfo such as individual hook?

[zixuan-wu]

hi, @jcranmer-intel , could you please propose a backend demo revision to demonstrate how to use targetext type of backend?

[hctim]

Hey, looks like this patch may have introduced a memory leak, as reported below by ASan.

This is caught on my local machine, which doesn't use an asan-instrumented libcxx (like our bots do). This does result in some false negatives, so an instrumented libcxx is always a better option, but this is a nice fast build for me to reproduce failures and bisect faster.

The stack trace points to a std::string heap leak, and so my hunch was that the bots didn't pick up this failure due to the different point at which libcxx and libstdc++ stop inlining the string and push it off to the heap. That turned out to be correct, changing the test like so even makes it reproduce using an instrumented libcxx (and thus the bots upstream):

diff --git a/llvm/test/Assembler/target-types.ll b/llvm/test/Assembler/target-types.ll
index 741a1a159678..7497fa8806df 100644
--- a/llvm/test/Assembler/target-types.ll
+++ b/llvm/test/Assembler/target-types.ll
@@ -1,7 +1,7 @@
 ; RUN: llvm-as < %s | llvm-dis | FileCheck %s
 ; Check support for basic target extension type usage

-@global = global target("spirv.DeviceEvent") zeroinitializer
+@global = global target("spirv.DeviceEventXXXXXX") zeroinitializer

 define target("spirv.Sampler") @foo(target("spirv.Sampler") %a) {
   ret target("spirv.Sampler") %a
@@ -13,7 +13,7 @@ define target("spirv.Event") @func2() {
   ret target("spirv.Event") poison
 }

-; CHECK: @global = global target("spirv.DeviceEvent") zeroinitializer
+; CHECK: @global = global target("spirv.DeviceEventXXXXXX") zeroinitializer
 ; CHECK: define target("spirv.Sampler") @foo(target("spirv.Sampler") %a) {
 ; CHECK:   ret target("spirv.Sampler") %a
 ; CHECK: }

My invocation for the "fast asan build" and the breaking unit test which uses libstdc++ is below. This fails at e6b02214c68df2c9f826e02310c9352ac652e456 (this commit) but passes the commit before.

$ cmake \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DLLVM_USE_LINKER=lld \
-GNinja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_FLAGS="-fsanitize=address" \
-DCMAKE_CXX_FLAGS="-fsanitize=address" \
-DLLVM_ENABLE_PROJECTS="'clang;lld;clang-tools-extra;mlir'" \
-DLLVM_LIBC_ENABLE_LINTING=OFF \
-DLLVM_USE_SANITIZER=Address \
/llvm
$ LIT_OPTS='--filter=Assembler/target-types.ll' ninja check-llvm
Direct leak of 18 byte(s) in 1 object(s) allocated from:
    #0 0x557fdbae956d in operator new(unsigned long) /compiler-rt/lib/asan/asan_new_delete.cpp:95:3
    #1 0x557fdbeb4f33 in _M_construct<const char *> /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.tcc:225:14
    #2 0x557fdbeb4f33 in basic_string /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:620:2
    #3 0x557fdbeb4f33 in basic_string /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:188:9
    #4 0x557fdbeb4f33 in basic_string<llvm::StringRef, void> /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/basic_string.h:787:4
    #5 0x557fdbeb4f33 in llvm::TargetExtType::TargetExtType(llvm::LLVMContext&, llvm::StringRef, llvm::ArrayRef<llvm::Type*>, llvm::ArrayRef<unsigned int>) /llvm/lib/IR/Type.cpp:796:31
    #6 0x557fdbeb6104 in llvm::TargetExtType::get(llvm::LLVMContext&, llvm::StringRef, llvm::ArrayRef<llvm::Type*>, llvm::ArrayRef<unsigned int>) /llvm/lib/IR/Type.cpp:830:14
    #7 0x557fdbb8ce03 in parseTypeTableBody /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2514:18
    #8 0x557fdbb8ce03 in parseTypeTable /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2252:10
    #9 0x557fdbb8ce03 in (anonymous namespace)::BitcodeReader::parseModule(unsigned long, bool, llvm::function_ref<std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>> (llvm::StringRef)>) /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:4245:25
    #10 0x557fdbb056e3 in parseBitcodeInto /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:4476:10
    #11 0x557fdbb056e3 in llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool, llvm::function_ref<std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>> (llvm::StringRef)>) /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:7927:22
    #12 0x557fdbb09212 in llvm::BitcodeModule::getLazyModule(llvm::LLVMContext&, bool, bool) /llvm/lib/Bitcode/Reader/BitcodeReader.cpp:7946:10
    #13 0x557fdbaf1144 in main /llvm/tools/llvm-dis/llvm-dis.cpp:205:16
    #14 0x7f137e229209 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: 18 byte(s) leaked in 1 allocation(s).

[jcranmer-intel]

In D135202#4022488, @zixuan-wu wrote:

hi, @jcranmer-intel , could you please propose a backend demo revision to demonstrate how to use targetext type of backend?

I don't have an example backend that goes through GlobalISel or SelectionDAG yet; I've been focusing my effort on the production SPIR-V backend which translates to SPIR-V straight from LLVM IR.

There may need to be some additional work to map these types to appropriate MVT types in the codegen phases, but my knowledge of codegen infrastructure is somewhat shaky, and this is highly dependent on how different backends wish to translate these types.

In D135202#4026617, @hctim wrote:

Hey, looks like this patch may have introduced a memory leak, as reported below by ASan.

That is a good catch. I have a fix for this, I think, in https://reviews.llvm.org/D141083 -- can you test it out?

llvm/lib/IR/Type.cpp

839

Yes.

852

In principle, it is possible to provide target hooks that could let individual targets define their own TargetTypeInfo tables. However, there is a bit of a layering issue: the information needed is too verbose to stuff into a datalayout string, and the existing target hooks aren't in a place where they can make it to DataLayout (who needs to know the size) or Verifier (for the other properties). Something new would have to be added, and it's not clear that it provides significant advantages over a hardcoded list for now.

[zixuan-wu]

llvm/lib/IR/Type.cpp

852

It's OK for me to evolve or iterate the hardcoded problem later.

[zixuan-wu]

I don't have an example backend that goes through GlobalISel or SelectionDAG yet; I've been focusing my effort on the production SPIR-V backend which translates to SPIR-V straight from LLVM IR.

There may need to be some additional work to map these types to appropriate MVT types in the codegen phases, but my knowledge of codegen infrastructure is somewhat shaky, and this is highly dependent on how different backends wish to translate these types.

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

[nikic]

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects.

Moving x86_amx to use a target-extension type would be great.

[jcranmer-intel]

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

[pengfei]

In D135202#4040194, @jcranmer-intel wrote:

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

I think it's more appropriate to start with x86_fp80 and x86_mmx. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX, <8x8xi8> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

[craig.topper]

In D135202#4042268, @pengfei wrote:

In D135202#4040194, @jcranmer-intel wrote:

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

I think it's more appropriate to start with x86_fp80 and x86_mmx. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX, <8x8xi8> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

Aren't both x86_fp80 and x86_mmx recognized by InstCombine? They aren't truly opaque.

[LuoYuanke]

In D135202#4042297, @craig.topper wrote:

In D135202#4042268, @pengfei wrote:

In D135202#4040194, @jcranmer-intel wrote:

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

I think it's more appropriate to start with x86_fp80 and x86_mmx. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX, <8x8xi8> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

Aren't both x86_fp80 and x86_mmx recognized by InstCombine? They aren't truly opaque.

x86_amx is also recognized by InstCombine, but may not as much as x86_mmx.

[zixuan-wu]

In D135202#4042268, @pengfei wrote:

In D135202#4040194, @jcranmer-intel wrote:

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

I think it's more appropriate to start with x86_fp80 and x86_mmx. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX, <8x8xi8> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

Well, as chris's @lattner comment of TLX which I also prefer, it's not a good way to support high level type in LLVM IR such as Matrix(or multi-dimension vector). We can convert matrix to fixed vector type and leverage with those intrinsics matrix-intrinsics, if we need fixed sized matrix. I am not sure whether it's sustainable and workable to completely develop AMX feature. For example, need we distinguish vector type and matrix when we addRegisterClass? And another point is do we really need different shape matrix in LLVM IR or just one type called x86amx?

[zixuan-wu]

In D135202#4042297, @craig.topper wrote:

In D135202#4042268, @pengfei wrote:

In D135202#4040194, @jcranmer-intel wrote:

In D135202#4038774, @zixuan-wu wrote:

I'd like to enable the backend infra and propose draft later. To better demonstrate and enable backend target-independent code completely, I'd like to demonstrate with x86_amx that changing x86_amx type to target extension type and make all test passed, if nobody objects. @jcranmer-intel @LuoYuanke @craig.topper @pengfei

I have no objections to this; indeed, my original proposal for target extension types included x86_mmx and x86_amx as types that could be implemented as target extension types. However, I'm not involved with the x86 backend, so I must defer to the proper codeowners there as to whether or not to do this.

I think it's more appropriate to start with x86_fp80 and x86_mmx. I'd expect there will be a more general matrix representation for the AMX type, e.g., TLX, <8x8xi8> etc. rather than limit it to target extension type, though I'm not against to do prototype for it.

Aren't both x86_fp80 and x86_mmx recognized by InstCombine? They aren't truly opaque.

Now I am not sure whether it still needs to respect the mmx or amx type in InstCombine. Maybe it can be removed, or respect the target extension type directly instead.

[zixuan-wu]

@jcranmer-intel hi, have you considered how to design and implement target extension type in clang front-end? For example, one solution is by attribute like following(maybe similar):

struct {
  int a;
  float b;
} __attribute__((target_ext_type("spirv.DeviceEvent", int, float)))

Or

typedef int[M] TType __attribute__((target_ext_type("spirv.DeviceEvent", int, m)))

so that it can specify the underlying type by typedef one original type.

Even with builtin type like following

typedef __rvv_buitlin_type TType __attribute__((target_ext_type("spirv.DeviceEvent")))

[jcranmer-intel]

In D135202#4226539, @zixuan-wu wrote:

@jcranmer-intel hi, have you considered how to design and implement target extension type in clang front-end?

I don't work too much in the Clang frontend, so you'd get better commentary by talking to people who work more specifically on the frontend pieces.

For my own personal opinion, I would be extremely reluctant to suggest a generic attribute-based approach to generate these types in the frontend. Instead, I suspect creating custom clang::Type is likely to be a more maintainable path: target extension types come with their own varied restrictions, and it's better to front those restrictions as early in the frontend as possible. For the target extension types I've needed for SPIR-V, almost all of them are existing already as clang::BuiltinType IDs, and the other types that have been looking at target extension types I believe also have other distinct types in the Clang frontend. Adding a new such builtin type isn't a very high maintenance burden. Things get more interesting if the types have parameters (which means you can't just add a new builtin type), but the need to do some form of AST and Sema analysis on such parameters likely requires you to have to do some modifications to clang anyways.

llvm/docs/BitCodeFormat.rst

 
 TYPE_CODE_X86_AMX Record
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ``[X86_AMX]``
 
 The ``X86_AMX`` record (code 24) adds an ``x86_amx`` type to the type table.
 
+TYPE_CODE_OPAQUE_TYPE Record
+^^^^^^^^^^^^^^^^^^^^^^^
+
+``[OPAQUE_TYPE, num_tys, ...ty_params..., ...int_params... ]``
+
+The ``OPAQUE_TYPE`` record (code 26) adds an opaque type to the type
+table, with a name defined by a previously encountered ``STRUCT_NAME`` record.
+The operand fields are
+
+* *num_tys*: The number of parameters that are types (as opposed to integers)
+
+* *ty_params*: Type indices that represent type parameters
+
+* *int_params*: Numbers that correspond to the integer parameters.
+
 .. _CONSTANTS_BLOCK:
 
 CONSTANTS_BLOCK Contents
 ------------------------
 
 The ``CONSTANTS_BLOCK`` block (id 11) ...
 
 .. _FUNCTION_BLOCK:

llvm/docs/LangRef.rst

 are target-specific. For example, ``ptr addrspace(5)`` is a pointer
 to address space 5.
 
 Prior to LLVM 15, pointer types also specified a pointee type, such as
 ``i8*``, ``[4 x i32]*`` or ``i32 (i32*)*``. In LLVM 15, such "typed
 pointers" are still supported under non-default options. See the
 `opaque pointers document <OpaquePointers.html>`__ for more information.
 
+.. _t_opaque_type:
+
+Opaque Type
+"""""""""""
+
+:Overview:
+
+Opaque types represent types that must be preserved through optimization, but
+are otherwise generally opaque to the compiler. They may be used as function
+parameters or arguments, and in :ref:`phi <i_phi>` or :ref:`select <i_select>`
+instructions. They may be also used in :ref:`alloca <i_alloca>` instructions or
+as global values, and correspondingly it is legal to use :ref:`load <i_load>`
+and :ref:`store <i_store>` instructions on them.
+
+The only constants that opaque types may have are ``zeroinitializer``,
+``undef``, and ``poison``. Other possible values for opaque types may arise from
+target-specific intrinsics and functions.
+
+While at first glance, these types may seem similar to pointer types, these
+types cannot be converted to other types. As such, it is not legal to use them
+in :ref:`bitcast <i_bitcast>` instructions (as a source or target type), nor is
+it legal to use them in :ref:`ptrtoint <i_ptrtoint>` or
+:ref:`inttoptr <i_inttoptr>` instructions. Similarly, they are not legal to use
+in an :ref:`icmp <i_icmp>` instruction.
+
+Opaque types have a name and optional type or integer parameters. The meanings
+of name and parameters are defined by the target. When being defined in LLVM IR,
+all of the type parameters must precede all of the integer parameters.
+
+:Syntax:
+
+.. code-block:: llvm
+
+      opaque("label")
+      opaque("label", void)
+      opaque("label", void, i32)
+      opaque("label", 0, 1, 2)
+      opaque("label", void, i32, 0, 1, 2)
+
+
 .. _t_vector:
 
 Vector Type
 """""""""""
 
 :Overview:
 
 A vector type is a simple derived type that represents a vector of

llvm/include/llvm-c/Core.h

typedef enum {
   LLVMArrayTypeKind,     /**< Arrays */
   LLVMPointerTypeKind,   /**< Pointers */
   LLVMVectorTypeKind,    /**< Fixed width SIMD vector type */
   LLVMMetadataTypeKind,  /**< Metadata */
   LLVMX86_MMXTypeKind,   /**< X86 MMX */
   LLVMTokenTypeKind,     /**< Tokens */
   LLVMScalableVectorTypeKind, /**< Scalable SIMD vector type */
   LLVMBFloatTypeKind,    /**< 16 bit brain floating point type */
-  LLVMX86_AMXTypeKind    /**< X86 AMX */
+  LLVMX86_AMXTypeKind,   /**< X86 AMX */
+  LLVMOpaqueTypeKind,    /**< Sized opaque type */
 } LLVMTypeKind;
 
 typedef enum {
   LLVMExternalLinkage,    /**< Externally visible function */
   LLVMAvailableExternallyLinkage,
   LLVMLinkOnceAnyLinkage, /**< Keep one copy of function when linking (inline)*/
   LLVMLinkOnceODRLinkage, /**< Same, but only replaced by something
                             equivalent. */
typedef enum {
   LLVMConstantPointerNullValueKind,
   LLVMConstantTokenNoneValueKind,
 
   LLVMMetadataAsValueValueKind,
   LLVMInlineAsmValueKind,
 
   LLVMInstructionValueKind,
   LLVMPoisonValueValueKind
 } LLVMValueKind;
 
 typedef enum {
   LLVMIntEQ = 32, /**< equal */
   LLVMIntNE,      /**< not equal */
   LLVMIntUGT,     /**< unsigned greater than */
   LLVMIntUGE,     /**< unsigned greater or equal */
   LLVMIntULT,     /**< unsigned less than */
   LLVMIntULE,     /**< unsigned less or equal */

  * global context.
  */
 LLVMTypeRef LLVMVoidType(void);
 LLVMTypeRef LLVMLabelType(void);
 LLVMTypeRef LLVMX86MMXType(void);
 LLVMTypeRef LLVMX86AMXType(void);
 
 /**
+ * Create an opaque type in LLVM context.
+ */
+LLVMTypeRef LLVMOpaqueTypeInContext(LLVMContextRef C, const char *Name,
+                                    LLVMTypeRef *TypeParams,
+                                    unsigned TypeParamCount,
+                                    unsigned *IntParams,
+                                    unsigned IntParamCount);
+
+
+/**
  * @}
  */
 
 /**
  * @}
  */
 
 /**

llvm/include/llvm/AsmParser/LLParser.h

private:
     bool parseAnonStructType(Type *&Result, bool Packed);
     bool parseStructBody(SmallVectorImpl<Type *> &Body);
     bool parseStructDefinition(SMLoc TypeLoc, StringRef Name,
                                std::pair<Type *, LocTy> &Entry,
                                Type *&ResultTy);
 
     bool parseArrayVectorType(Type *&Result, bool IsVector);
     bool parseFunctionType(Type *&Result);
+    bool parseOpaqueType(Type *&Result);
 
     // Function Semantic Analysis.
     class PerFunctionState {
       LLParser &P;
       Function &F;
       std::map<std::string, std::pair<Value*, LocTy> > ForwardRefVals;
       std::map<unsigned, std::pair<Value*, LocTy> > ForwardRefValIDs;
       std::vector<Value*> NumberedVals;

llvm/include/llvm/Bitcode/LLVMBitCodes.h

enum TypeCodes {
   TYPE_CODE_FUNCTION = 21, // FUNCTION: [vararg, retty, paramty x N]
 
   TYPE_CODE_TOKEN = 22, // TOKEN
 
   TYPE_CODE_BFLOAT = 23,  // BRAIN FLOATING POINT
   TYPE_CODE_X86_AMX = 24, // X86 AMX
 
   TYPE_CODE_OPAQUE_POINTER = 25, // OPAQUE_POINTER: [addrspace]
+
+  TYPE_CODE_OPAQUE_TYPE = 26, // OPAQUE_TYPE
 };
 
 enum OperandBundleTagCode {
   OPERAND_BUNDLE_TAG = 1, // TAG: [strchr x N]
 };
 
 enum SyncScopeNameCode {
   SYNC_SCOPE_NAME = 1,

llvm/include/llvm/IR/DataLayout.h

 };
 
 // The implementation of this method is provided inline as it is particularly
 // well suited to constant folding when called on a specific Type subclass.
 inline TypeSize DataLayout::getTypeSizeInBits(Type *Ty) const {
   assert(Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!");
   switch (Ty->getTypeID()) {
   case Type::LabelTyID:
+  case Type::OpaqueTyID:
     return TypeSize::Fixed(getPointerSizeInBits(0));
   case Type::PointerTyID:
     return TypeSize::Fixed(getPointerSizeInBits(Ty->getPointerAddressSpace()));
   case Type::ArrayTyID: {
     ArrayType *ATy = cast<ArrayType>(Ty);
     return ATy->getNumElements() *
            getTypeAllocSizeInBits(ATy->getElementType());
   }
   case Type::StructTyID:

llvm/include/llvm/IR/DerivedTypes.h

assert(
       "Original type expected to be a vector of integers or a scalar integer.");
   return getWithNewType(getIntNTy(getContext(), NewBitWidth));
 }
 
 unsigned Type::getPointerAddressSpace() const {
   return cast<PointerType>(getScalarType())->getAddressSpace();
 }
 
+/// Class to represent opaque types, which are generally unintrospectable from
+/// target-independent optimizations.
+///
+/// Opaque types have a string name, and optionally have type and/or integer
+/// parameters. The exact meaning of any parameters is dependent on the target.
+class OpaqueType : public Type {
+  OpaqueType(LLVMContext &C, StringRef Name, ArrayRef<Type *> Types,
+             ArrayRef<unsigned> Ints);
+
+  std::string Name;
+  unsigned *IntParams;
+
+public:
+  OpaqueType(const OpaqueType &) = delete;
+  OpaqueType &operator=(const OpaqueType &) = delete;
+
+  /// Return an opaque type having the specified name and no type or integer
+  /// parameters.
+  static OpaqueType *get(LLVMContext &Context, StringRef Name) {
+    return get(Context, Name, {}, {});
+  }
+
+  /// Return an opaque type having the specified name, type, and integer
+  /// parameters.
+  static OpaqueType *get(LLVMContext &Context, StringRef Name,
+                         ArrayRef<Type *> Types, ArrayRef<unsigned> Ints);
+
+  /// Return the name for this opaque type. Two distinct opaque types may have
+  /// the same name if their type or integer parameters differ.
+  StringRef getName() const { return Name; }
+
+  /// Return the type parameters for this particular opaque type. If there are
+  /// no parameters, an empty array is returned.
+  ArrayRef<Type *> type_params() const {
+    return makeArrayRef(type_param_begin(), type_param_end());
+  }
+
+  using type_param_iterator = Type::subtype_iterator;
+  type_param_iterator type_param_begin() const { return ContainedTys; }
+  type_param_iterator type_param_end() const {
+    return &ContainedTys[NumContainedTys];
+  }
+
+  Type *getTypeParameter(unsigned i) const { return getContainedType(i); }
+  unsigned getNumTypeParameters() const { return getNumContainedTypes(); }
+
+  /// Return the integer parameters for this particular opaque type. If there
+  /// are no parameters, an empty array is returned.
+  ArrayRef<unsigned> int_params() const {
+    return makeArrayRef(IntParams, getNumIntParameters());
+  }
+
+  unsigned getIntParameter(unsigned i) const { return IntParams[i]; }
+  unsigned getNumIntParameters() const { return getSubclassData(); }
+
+  /// Methods for support type inquiry through isa, cast, and dyn_cast.
+  static bool classof(const Type *T) { return T->getTypeID() == OpaqueTyID; }
+};
+
+StringRef Type::getOpaqueName() const {
+  return cast<OpaqueType>(this)->getName();
+}
+
 } // end namespace llvm
 
 #endif // LLVM_IR_DERIVEDTYPES_H

llvm/include/llvm/IR/Type.h

enum TypeID {
     IntegerTyID,        ///< Arbitrary bit width integers
     FunctionTyID,       ///< Functions
     PointerTyID,        ///< Pointers
     StructTyID,         ///< Structures
     ArrayTyID,          ///< Arrays
     FixedVectorTyID,    ///< Fixed width SIMD vector type
     ScalableVectorTyID, ///< Scalable SIMD vector type
     TypedPointerTyID,   ///< Typed pointer used by some GPU targets
+    OpaqueTyID,         ///< Sized opaque types
   };
 
 private:
   /// This refers to the LLVMContext in which this type was uniqued.
   LLVMContext &Context;
 
   TypeID   ID : 8;            // The current base type of this type.
   unsigned SubclassData : 24; // Space for subclasses to store data.
public:
   const fltSemantics &getFltSemantics() const;
 
   /// Return true if this is X86 MMX.
   bool isX86_MMXTy() const { return getTypeID() == X86_MMXTyID; }
 
   /// Return true if this is X86 AMX.
   bool isX86_AMXTy() const { return getTypeID() == X86_AMXTyID; }
 
+  /// Return true if this is a sized opaque type.
+  bool isOpaqueTy() const { return getTypeID() == OpaqueTyID; }
+
   /// Return true if this is a FP type or a vector of FP.
   bool isFPOrFPVectorTy() const { return getScalarType()->isFloatingPointTy(); }
 
   /// Return true if this is 'label'.
   bool isLabelTy() const { return getTypeID() == LabelTyID; }
 
   /// Return true if this is 'metadata'.
   bool isMetadataTy() const { return getTypeID() == MetadataTyID; }
public:
   bool isFirstClassType() const {
     return getTypeID() != FunctionTyID && getTypeID() != VoidTyID;
   }
 
   /// Return true if the type is a valid type for a register in codegen. This
   /// includes all first-class types except struct and array types.
   bool isSingleValueType() const {
     return isFloatingPointTy() || isX86_MMXTy() || isIntegerTy() ||
-           isPointerTy() || isVectorTy() || isX86_AMXTy();
+           isPointerTy() || isVectorTy() || isX86_AMXTy() || isOpaqueTy();
   }
 
   /// Return true if the type is an aggregate type. This means it is valid as
   /// the first operand of an insertvalue or extractvalue instruction. This
   /// includes struct and array types, but does not include vector types.
   bool isAggregateType() const {
     return getTypeID() == StructTyID || getTypeID() == ArrayTyID;
   }
 
   /// Return true if it makes sense to take the size of this type. To get the
   /// actual size for a particular target, it is reasonable to use the
   /// DataLayout subsystem to do this.
   bool isSized(SmallPtrSetImpl<Type*> *Visited = nullptr) const {
     // If it's a primitive, it is always sized.
     if (getTypeID() == IntegerTyID || isFloatingPointTy() ||
         getTypeID() == PointerTyID || getTypeID() == X86_MMXTyID ||
-        getTypeID() == X86_AMXTyID)
+        getTypeID() == X86_AMXTyID || getTypeID() == OpaqueTyID)
       return true;
     // If it is not something that can have a size (e.g. a function or label),
     // it doesn't have a size.
     if (getTypeID() != StructTyID && getTypeID() != ArrayTyID && !isVectorTy())
       return false;
     // Otherwise we have to try harder to decide.
     return isSizedDerivedType(Visited);
   }
public:
 
   inline uint64_t getArrayNumElements() const;
 
   Type *getArrayElementType() const {
     assert(getTypeID() == ArrayTyID);
     return ContainedTys[0];
   }
 
+  inline StringRef getOpaqueName() const;
+
   /// This method is deprecated without replacement. Pointer element types are
   /// not available with opaque pointers.
   [[deprecated("Deprecated without replacement, see "
                "https://llvm.org/docs/OpaquePointers.html for context and "
                "migration instructions")]]
   Type *getPointerElementType() const {
     return getNonOpaquePointerElementType();
   }

llvm/lib/AsmParser/LLParser.cpp

if (Result->isOpaquePointerTy()) {
 
       // Fall through to parsing the type suffixes only if this 'ptr' is a
       // function return. Otherwise, return success, implicitly rejecting other
       // suffixes.
       if (Lex.getKind() != lltok::lparen)
         return false;
     }
     break;
+  case lltok::kw_opaque: {
+    // Type ::= OpaqueType
+    if (parseOpaqueType(Result))
+      return true;
+    break;
+  }
   case lltok::lbrace:
     // Type ::= StructType
     if (parseAnonStructType(Result, false))
       return true;
     break;
   case lltok::lsquare:
     // Type ::= '[' ... ']'
     Lex.Lex(); // eat the lsquare.
bool LLParser::parseArrayVectorType(Type *&Result, bool IsVector) {
   } else {
     if (!ArrayType::isValidElementType(EltTy))
       return error(TypeLoc, "invalid array element type");
     Result = ArrayType::get(EltTy, Size);
   }
   return false;
 }
 
+/// parseOpaqueType - handle opaque type syntax
+///   OpaqueType
+///     ::= 'opaque' '(' STRINGCONSTANT OpaqueTypeParams OpaqueIntParams ')'
+///
+///   OpaqueTypeParams
+///     ::= /*empty*/
+///     ::= ',' Type OpaqueTypeParams
+///
+///   OpaqueIntParams
+///     ::= /*empty*/
+///     ::= ',' uint32 OpaqueIntParams
+bool LLParser::parseOpaqueType(Type *&Result) {
+  Lex.Lex(); // Eat the 'opaque' keyword.
+
+  // Get the mandatory opaque type name.
+  std::string OpaqueName;
+  if (parseToken(lltok::lparen, "expected '(' in opaque type") ||
+      parseStringConstant(OpaqueName))
+    return true;
+
+  // Parse all of the integer and type parameters at the same time; the use of
+  // SeenInt will allow us to catch cases where type parameters follow integer
+  // parameters.
+  SmallVector<Type *, 4> TypeParams;
+  SmallVector<unsigned, 8> IntParams;
+  bool SeenInt = false;
+  while (Lex.getKind() == lltok::comma) {
+    Lex.Lex(); // Eat the comma.
+
+    if (Lex.getKind() == lltok::APSInt) {
+      SeenInt = true;
+      unsigned IntVal;
+      if (parseUInt32(IntVal))
+        return true;
+      IntParams.push_back(IntVal);
+    } else if (SeenInt) {
+      // The only other kind of parameter we support is type parameters, which
+      // must precede the integer parameters. This is therefore an error.
+      return tokError("expected uint32 param");
+    } else {
+      Type *TypeParam;
+      if (parseType(TypeParam, /*AllowVoid=*/true))
+        return true;
+      TypeParams.push_back(TypeParam);
+    }
+  }
+
+  if (parseToken(lltok::rparen, "expected ')' in opaque type"))
+    return true;
+
+  Result = OpaqueType::get(Context, OpaqueName, TypeParams, IntParams);
+  return false;
+}
+
 //===----------------------------------------------------------------------===//
 // Function Semantic Analysis.
 //===----------------------------------------------------------------------===//
 
 LLParser::PerFunctionState::PerFunctionState(LLParser &p, Function &f,
                                              int functionNumber)
   : P(p), F(f), FunctionNumber(functionNumber) {
 

llvm/lib/Bitcode/Reader/BitcodeReader.cpp

case bitc::TYPE_CODE_OPAQUE: {       // OPAQUE: []
         Res->setName(TypeName);
         TypeList[NumRecords] = nullptr;
       } else  // Otherwise, create a new struct with no body.
         Res = createIdentifiedStructType(Context, TypeName);
       TypeName.clear();
       ResultTy = Res;
       break;
     }
+    case bitc::TYPE_CODE_OPAQUE_TYPE: { // OPAQUE_TYPE: [NumTy, Tys..., Ints...]
+      if (Record.size() < 1)
+        return error("Invalid opaque type record");
+
+      if (NumRecords >= TypeList.size())
+        return error("Invalid TYPE table");
+
+      if (Record[0] >= Record.size())
+        return error("Too many type parameters");
+
+      unsigned NumTys = Record[0];
+      SmallVector<Type *, 4> TypeParams;
+      SmallVector<unsigned, 8> IntParams;
+      for (unsigned i = 0; i < NumTys; i++) {
+        if (Type *T = getTypeByID(Record[i + 1]))
+          TypeParams.push_back(T);
+        else
+          return error("Invalid type");
+      }
+
+      for (unsigned i = NumTys + 1, e = Record.size(); i < e; i++) {
+        if (Record[i] > UINT_MAX)
+          return error("Integer parameter too large");
+        IntParams.push_back(Record[i]);
+      }
+      ResultTy = OpaqueType::get(Context, TypeName, TypeParams, IntParams);
+      TypeName.clear();
+      break;
+    }
     case bitc::TYPE_CODE_ARRAY:     // ARRAY: [numelts, eltty]
       if (Record.size() < 2)
         return error("Invalid array type record");
       ResultTy = getTypeByID(Record[1]);
       if (!ResultTy || !ArrayType::isValidElementType(ResultTy))
         return error("Invalid type");
       ContainedIDs.push_back(Record[1]);
       ResultTy = ArrayType::get(ResultTy, Record[0]);

llvm/lib/Bitcode/Writer/BitcodeWriter.cpp

case Type::ScalableVectorTyID: {
       //        [numelts, eltty, scalable]
       Code = bitc::TYPE_CODE_VECTOR;
       TypeVals.push_back(VT->getElementCount().getKnownMinValue());
       TypeVals.push_back(VE.getTypeID(VT->getElementType()));
       if (isa<ScalableVectorType>(VT))
         TypeVals.push_back(true);
       break;
     }
+    case Type::OpaqueTyID: {
+      OpaqueType *OT = cast<OpaqueType>(T);
+      Code = bitc::TYPE_CODE_OPAQUE_TYPE;
+      writeStringRecord(Stream, bitc::TYPE_CODE_STRUCT_NAME, OT->getName(),
+                        StructNameAbbrev);
+      TypeVals.push_back(OT->getNumTypeParameters());
+      for (Type *InnerTy : OT->type_params())
+        TypeVals.push_back(VE.getTypeID(InnerTy));
+      for (unsigned IntParam : OT->int_params())
+        TypeVals.push_back(IntParam);
+      break;
+    }
     case Type::TypedPointerTyID:
       llvm_unreachable("Typed pointers cannot be added to IR modules");
     }
 
     // Emit the finished record.
     Stream.EmitRecord(Code, TypeVals, AbbrevToUse);
     TypeVals.clear();
   }

llvm/lib/IR/AsmWriter.cpp

case Type::ScalableVectorTyID: {
     return;
   }
   case Type::TypedPointerTyID: {
     TypedPointerType *TPTy = cast<TypedPointerType>(Ty);
     OS << "typedptr(" << *TPTy->getElementType() << ", "
        << TPTy->getAddressSpace() << ")";
     return;
   }
+  case Type::OpaqueTyID:
+    OpaqueType *OTy = cast<OpaqueType>(Ty);
+    OS << "opaque(\"";
+    printEscapedString(Ty->getOpaqueName(), OS);
+    OS << "\"";
+    for (Type *Inner : OTy->type_params())
+      OS << ", " << *Inner;
+    for (unsigned IntParam : OTy->int_params())
+      OS << ", " << IntParam;
+    OS << ")";
+    return;
   }
   llvm_unreachable("Invalid TypeID");
 }
 
 void TypePrinting::printStructBody(StructType *STy, raw_ostream &OS) {
   if (STy->isOpaque()) {
     OS << "opaque";
     return;

llvm/lib/IR/Constants.cpp

case Type::PPC_FP128TyID:
     return ConstantFP::get(Ty->getContext(),
                            APFloat::getZero(Ty->getFltSemantics()));
   case Type::PointerTyID:
     return ConstantPointerNull::get(cast<PointerType>(Ty));
   case Type::StructTyID:
   case Type::ArrayTyID:
   case Type::FixedVectorTyID:
   case Type::ScalableVectorTyID:
+  case Type::OpaqueTyID:
     return ConstantAggregateZero::get(Ty);
   case Type::TokenTyID:
     return ConstantTokenNone::get(Ty->getContext());
   default:
     // Function, Label, or Opaque type?
     llvm_unreachable("Cannot create a null constant of that type!");
   }
 }

 }
 
 ElementCount ConstantAggregateZero::getElementCount() const {
   Type *Ty = getType();
   if (auto *AT = dyn_cast<ArrayType>(Ty))
     return ElementCount::getFixed(AT->getNumElements());
   if (auto *VT = dyn_cast<VectorType>(Ty))
     return VT->getElementCount();
+  if (isa<OpaqueType>(Ty))
+    return ElementCount::getNull();
   return ElementCount::getFixed(Ty->getStructNumElements());
 }
 
 //===----------------------------------------------------------------------===//
 //                         UndefValue Implementation
 //===----------------------------------------------------------------------===//
 
 UndefValue *UndefValue::getSequentialElement() const {
bool ConstantFP::isValueValidForType(Type *Ty, const APFloat& Val) {
   }
 }
 
 
 //===----------------------------------------------------------------------===//
 //                      Factory Function Implementation
 
 ConstantAggregateZero *ConstantAggregateZero::get(Type *Ty) {
-  assert((Ty->isStructTy() || Ty->isArrayTy() || Ty->isVectorTy()) &&
+  assert((Ty->isStructTy() || Ty->isArrayTy() || Ty->isVectorTy() ||
+          Ty->isOpaqueTy()) &&
          "Cannot create an aggregate zero of non-aggregate type!");
 
   std::unique_ptr<ConstantAggregateZero> &Entry =
       Ty->getContext().pImpl->CAZConstants[Ty];
   if (!Entry)
     Entry.reset(new ConstantAggregateZero(Ty));
 
   return Entry.get();

llvm/lib/IR/Core.cpp

LLVMTypeKind LLVMGetTypeKind(LLVMTypeRef Ty) {
   case Type::X86_MMXTyID:
     return LLVMX86_MMXTypeKind;
   case Type::X86_AMXTyID:
     return LLVMX86_AMXTypeKind;
   case Type::TokenTyID:
     return LLVMTokenTypeKind;
   case Type::ScalableVectorTyID:
     return LLVMScalableVectorTypeKind;
+  case Type::OpaqueTyID:
+    return LLVMOpaqueTypeKind;
   case Type::TypedPointerTyID:
     llvm_unreachable("Typed pointers are unsupported via the C API");
   }
   llvm_unreachable("Unhandled TypeID.");
 }
 
 LLVMBool LLVMTypeIsSized(LLVMTypeRef Ty)
 {

 
 LLVMTypeRef LLVMVoidType(void)  {
   return LLVMVoidTypeInContext(LLVMGetGlobalContext());
 }
 LLVMTypeRef LLVMLabelType(void) {
   return LLVMLabelTypeInContext(LLVMGetGlobalContext());
 }
 
+LLVMTypeRef LLVMOpaqueTypeInContext(LLVMContextRef C, const char *Name,
+                                    LLVMTypeRef *TypeParams,
+                                    unsigned TypeParamCount,
+                                    unsigned *IntParams,
+                                    unsigned IntParamCount) {
+  ArrayRef<Type *> TypeParamArray(unwrap(TypeParams), TypeParamCount);
+  ArrayRef<unsigned> IntParamArray(IntParams, IntParamCount);
+  return wrap(OpaqueType::get(*unwrap(C), Name, TypeParamArray, IntParamArray));
+}
+
 /*===-- Operations on values ----------------------------------------------===*/
 
 /*--.. Operations on all values ............................................--*/
 
 LLVMTypeRef LLVMTypeOf(LLVMValueRef Val) {
   return wrap(unwrap(Val)->getType());
 }
 

llvm/lib/IR/DataLayout.cpp

/*!
   Get the ABI (\a abi_or_pref == true) or preferred alignment (\a abi_or_pref
   == false) for the requested type \a Ty.
  */
 Align DataLayout::getAlignment(Type *Ty, bool abi_or_pref) const {
   assert(Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!");
   switch (Ty->getTypeID()) {
   // Early escape for the non-numeric types.
   case Type::LabelTyID:
+  case Type::OpaqueTyID:
     return abi_or_pref ? getPointerABIAlignment(0) : getPointerPrefAlignment(0);
   case Type::PointerTyID: {
     unsigned AS = cast<PointerType>(Ty)->getAddressSpace();
     return abi_or_pref ? getPointerABIAlignment(AS)
                        : getPointerPrefAlignment(AS);
     }
   case Type::ArrayTyID:
     return getAlignment(cast<ArrayType>(Ty)->getElementType(), abi_or_pref);

llvm/lib/IR/Function.cpp

if (PointerType *PTyp = dyn_cast<PointerType>(Ty)) {
     // Ensure nested function types are distinguishable.
     Result += "f";
   } else if (VectorType *VTy = dyn_cast<VectorType>(Ty)) {
     ElementCount EC = VTy->getElementCount();
     if (EC.isScalable())
       Result += "nx";
     Result += "v" + utostr(EC.getKnownMinValue()) +
               getMangledTypeStr(VTy->getElementType(), HasUnnamedType);
+  } else if (OpaqueType *OTy = dyn_cast<OpaqueType>(Ty)) {
+    Result += "o";
+    Result += OTy->getName();
   } else if (Ty) {
     switch (Ty->getTypeID()) {
     default: llvm_unreachable("Unhandled type");
     case Type::VoidTyID:      Result += "isVoid";   break;
     case Type::MetadataTyID:  Result += "Metadata"; break;
     case Type::HalfTyID:      Result += "f16";      break;
     case Type::BFloatTyID:    Result += "bf16";     break;
     case Type::FloatTyID:     Result += "f32";      break;

llvm/lib/IR/LLVMContextImpl.h

static bool isEqual(const KeyTy &LHS, const FunctionType *RHS) {
     return LHS == KeyTy(RHS);
   }
 
   static bool isEqual(const FunctionType *LHS, const FunctionType *RHS) {
     return LHS == RHS;
   }
 };
 
+struct OpaqueTypeKeyInfo {
+  struct KeyTy {
+    StringRef Name;
+    ArrayRef<Type *> TypeParams;
+    ArrayRef<unsigned> IntParams;
+
+    KeyTy(StringRef N, const ArrayRef<Type *> &TP, const ArrayRef<unsigned> &IP)
+        : Name(N), TypeParams(TP), IntParams(IP) {}
+    KeyTy(const OpaqueType *OT)
+        : Name(OT->getName()), TypeParams(OT->type_params()),
+          IntParams(OT->int_params()) {}
+
+    bool operator==(const KeyTy &that) const {
+      if (Name != that.Name)
+        return false;
+      if (TypeParams != that.TypeParams)
+        return false;
+      if (IntParams != that.IntParams)
+        return false;
+      return true;
+    }
+    bool operator!=(const KeyTy &that) const { return !this->operator==(that); }
+  };
+
+  static inline OpaqueType *getEmptyKey() {
+    return DenseMapInfo<OpaqueType *>::getEmptyKey();
+  }
+
+  static inline OpaqueType *getTombstoneKey() {
+    return DenseMapInfo<OpaqueType *>::getTombstoneKey();
+  }
+
+  static unsigned getHashValue(const KeyTy &Key) {
+    return hash_combine(
+        Key.Name,
+        hash_combine_range(Key.TypeParams.begin(), Key.TypeParams.end()),
+        hash_combine_range(Key.IntParams.begin(), Key.IntParams.end()));
+  }
+
+  static unsigned getHashValue(const OpaqueType *FT) {
+    return getHashValue(KeyTy(FT));
+  }
+
+  static bool isEqual(const KeyTy &LHS, const OpaqueType *RHS) {
+    if (RHS == getEmptyKey() || RHS == getTombstoneKey())
+      return false;
+    return LHS == KeyTy(RHS);
+  }
+
+  static bool isEqual(const OpaqueType *LHS, const OpaqueType *RHS) {
+    return LHS == RHS;
+  }
+};
+
 /// Structure for hashing arbitrary MDNode operands.
 class MDNodeOpsKey {
   ArrayRef<Metadata *> RawOps;
   ArrayRef<MDOperand> Ops;
   unsigned Hash;
 
 protected:
   MDNodeOpsKey(ArrayRef<Metadata *> Ops)
#include "llvm/IR/Metadata.def"
 
   using FunctionTypeSet = DenseSet<FunctionType *, FunctionTypeKeyInfo>;
   FunctionTypeSet FunctionTypes;
   using StructTypeSet = DenseSet<StructType *, AnonStructTypeKeyInfo>;
   StructTypeSet AnonStructTypes;
   StringMap<StructType *> NamedStructTypes;
   unsigned NamedStructTypesUniqueID = 0;
 
+  using OpaqueTypeSet = DenseSet<OpaqueType *, OpaqueTypeKeyInfo>;
+  OpaqueTypeSet OpaqueTypes;
+
   DenseMap<std::pair<Type *, uint64_t>, ArrayType *> ArrayTypes;
   DenseMap<std::pair<Type *, ElementCount>, VectorType *> VectorTypes;
   DenseMap<Type *, PointerType *> PointerTypes; // Pointers in AddrSpace = 0
   DenseMap<std::pair<Type *, unsigned>, PointerType *> ASPointerTypes;
   DenseMap<std::pair<Type *, unsigned>, TypedPointerType *> ASTypedPointerTypes;
 
   /// ValueHandles - This map keeps track of all of the value handles that are
   /// watching a Value*.  The Value::HasValueHandle bit is used to know

llvm/lib/IR/Type.cpp

bool PointerType::isValidElementType(Type *ElemTy) {
   return !ElemTy->isVoidTy() && !ElemTy->isLabelTy() &&
          !ElemTy->isMetadataTy() && !ElemTy->isTokenTy() &&
          !ElemTy->isX86_AMXTy();
 }
 
 bool PointerType::isLoadableOrStorableType(Type *ElemTy) {
   return isValidElementType(ElemTy) && !ElemTy->isFunctionTy();
 }
+
+//===----------------------------------------------------------------------===//
+//                       OpaqueType Implementation
+//===----------------------------------------------------------------------===//
+
+OpaqueType::OpaqueType(LLVMContext &C, StringRef Name, ArrayRef<Type *> Types,
+                       ArrayRef<unsigned> Ints)
+    : Type(C, OpaqueTyID), Name(Name) {
+  NumContainedTys = Types.size();
+
+  // Parameter storage immediately follows the class in allocation.
+  Type **Params = reinterpret_cast<Type **>(this + 1);
+  ContainedTys = Params;
+  for (Type *T : Types)
+    *Params++ = T;
+
+  setSubclassData(Ints.size());
+  unsigned *IntParamSpace = reinterpret_cast<unsigned *>(Params);
+  IntParams = IntParamSpace;
+  for (unsigned IntParam : Ints)
+    *IntParamSpace++ = IntParam;
+}
+
+OpaqueType *OpaqueType::get(LLVMContext &C, StringRef Name,
+                            ArrayRef<Type *> Types, ArrayRef<unsigned> Ints) {
+  const OpaqueTypeKeyInfo::KeyTy Key(Name, Types, Ints);
+  OpaqueType *OT;
+  // Since we only want to allocate a fresh opaque type in case none is found
+  // and we don't want to perform two lookups (one for checking if existent and
+  // one for inserting the newly allocated one), here we instead lookup based on
+  // Key and update the reference to the opaque type in-place to a newly
+  // allocated one if not found.
+  auto Insertion = C.pImpl->OpaqueTypes.insert_as(nullptr, Key);
+  if (Insertion.second) {
+    // The opaque type was not found. Allocate one and update OpaqueTypes
+    // in-place.
+    OT = (OpaqueType *)C.pImpl->Alloc.Allocate(
+        sizeof(OpaqueType) + sizeof(Type *) * Types.size() +
+            sizeof(unsigned) * Ints.size(),
+        alignof(OpaqueType));
+    new (OT) OpaqueType(C, Name, Types, Ints);
+    *Insertion.first = OT;
+  } else {
+    // The opaque type was found. Just return it.
+    OT = *Insertion.first;
+  }
+  return OT;
+}

llvm/lib/Transforms/Scalar/SROA.cpp

if (NewTy->isPointerTy() || OldTy->isPointerTy()) {
     // We can convert integral pointers to integers, but non-integral pointers
     // need to remain pointers.
     if (!DL.isNonIntegralPointerType(OldTy))
       return NewTy->isIntegerTy();
 
     return false;
   }
 
+  if (OldTy->isOpaqueTy() || NewTy->isOpaqueTy())
+    return false;
+
   return true;
 }
 
 /// Generic routine to convert an SSA value to a value of a different
 /// type.
 ///
 /// This will try various different casting techniques, such as bitcasts,
 /// inttoptr, and ptrtoint casts. Use the \c canConvertValue predicate to test

llvm/lib/Transforms/Utils/VNCoercion.cpp

return false;
              StoredTy->getPointerAddressSpace() !=
                  LoadTy->getPointerAddressSpace()) {
     return false;
   }
 
 
   // The implementation below uses inttoptr for vectors of unequal size; we
   // can't allow this for non integral pointers. We could teach it to extract
-  // exact subvectors if desired. 
+  // exact subvectors if desired.
   if (StoredNI && StoreSize != DL.getTypeSizeInBits(LoadTy).getFixedSize())
     return false;
 
+  if (StoredTy->isOpaqueTy() || LoadTy->isOpaqueTy())
+    return false;
+
   return true;
 }
 
 /// If we saw a store of a value to memory, and
 /// then a load from a must-aliased pointer of a different type, try to coerce
 /// the stored value.  LoadedTy is the type of the load we want to replace.
 /// IRB is IRBuilder used to insert new instructions.
 ///

llvm/test/Assembler/invalid-opaque-type-mixed.ll

+; RUN: not llvm-as < %s -disable-output 2>&1 | FileCheck %s
+
+; CHECK: expected uint32 param
+define void @f(opaque("type", i32, 0, void) %a) {
+    ret void
+}

llvm/test/Assembler/opaque-type-params.ll

+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+; Check support for basic opaque type properties
+
+@g1 = global opaque("atype", void) zeroinitializer
+@g2 = global opaque("atype", i32) zeroinitializer
+@g3 = global opaque("atype", i32, 0) zeroinitializer
+@g4 = global opaque("atype", 0) zeroinitializer
+@g5 = global opaque("atype", 0, 1, 2) zeroinitializer
+@g6 = global opaque("atype", void, i32, float, {i32, bfloat}, 0, 1, 2) zeroinitializer
+
+;CHECK: @g1 = global opaque("atype", void) zeroinitializer
+;CHECK: @g2 = global opaque("atype", i32) zeroinitializer
+;CHECK: @g3 = global opaque("atype", i32, 0) zeroinitializer
+;CHECK: @g4 = global opaque("atype", 0) zeroinitializer
+;CHECK: @g5 = global opaque("atype", 0, 1, 2) zeroinitializer
+;CHECK: @g6 = global opaque("atype", void, i32, float, { i32, bfloat }, 0, 1, 2) zeroinitializer

llvm/test/Assembler/opaque-types.ll

+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+; Check support for basic opaque type properties
+
+@global = global opaque("ctype") zeroinitializer
+
+define opaque("atype") @foo(opaque("atype") %a) {
+  ret opaque("atype") %a
+}
+
+define opaque("btype") @func2() {
+  %mem = alloca opaque("btype")
+  %val = load opaque("btype"), ptr %mem
+  ret opaque("btype") poison
+}
+
+; CHECK: @global = global opaque("ctype") zeroinitializer
+; CHECK: define opaque("atype") @foo(opaque("atype") %a) {
+; CHECK:   ret opaque("atype") %a
+; CHECK: }
+; CHECK: define opaque("btype") @func2() {
+; CHECK:   %mem = alloca opaque("btype")
+; CHECK:   %val = load opaque("btype"), ptr %mem
+; CHECK:   ret opaque("btype") poison
+; CHECK: }
+

llvm/test/Transforms/GVN/opaque-type.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -passes=gvn < %s | FileCheck %s
+
+; Check that GVN can work with opaque types correctly.
+
+target datalayout = "e-p:64:64:64-p1:16:16:16-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n8:16:32:64"
+
+define opaque("type") @basic_alloc(opaque("type") %arg) {
+; CHECK-LABEL: @basic_alloc(
+; CHECK-NEXT:    [[VAL:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    store opaque("type") [[ARG:%.*]], ptr [[VAL]], align 8
+; CHECK-NEXT:    ret opaque("type") [[ARG]]
+;
+  %val = alloca opaque("type")
+  store opaque("type") %arg, ptr %val
+  %ret = load opaque("type"), ptr %val
+  ret opaque("type") %ret
+}
+
+define opaque("type") @nobitcast(ptr %arg) {
+; CHECK-LABEL: @nobitcast(
+; CHECK-NEXT:    [[VAL:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    store ptr [[ARG:%.*]], ptr [[VAL]], align 8
+; CHECK-NEXT:    [[RET:%.*]] = load opaque("type"), ptr [[VAL]], align 8
+; CHECK-NEXT:    ret opaque("type") [[RET]]
+;
+  %val = alloca opaque("type")
+  store ptr %arg, ptr %val
+  %ret = load opaque("type"), ptr %val
+  ret opaque("type") %ret
+}
+
+define opaque("type") @viai64(opaque("type") %arg) {
+; CHECK-LABEL: @viai64(
+; CHECK-NEXT:    [[VAL:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    [[BAR:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    store opaque("type") [[ARG:%.*]], ptr [[VAL]], align 8
+; CHECK-NEXT:    [[IMEMCPY:%.*]] = load i64, ptr [[VAL]], align 4
+; CHECK-NEXT:    store i64 [[IMEMCPY]], ptr [[BAR]], align 4
+; CHECK-NEXT:    [[RET:%.*]] = load opaque("type"), ptr [[BAR]], align 8
+; CHECK-NEXT:    ret opaque("type") [[RET]]
+;
+  %val = alloca opaque("type")
+  %bar = alloca opaque("type")
+  store opaque("type") %arg, ptr %val
+  %imemcpy = load i64, ptr %val
+  store i64 %imemcpy, ptr %bar
+  %ret = load opaque("type"), ptr %bar
+  ret opaque("type") %ret
+}
+
+declare void @llvm.memcpy.p0.p0.i64(ptr, ptr, i64, i1)

llvm/test/Transforms/SROA/sroa-opaque.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -passes=sroa < %s | FileCheck %s
+
+; Check that SROA can work with opaque types correctly.
+
+target datalayout = "e-p:64:64:64-p1:16:16:16-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n8:16:32:64"
+
+define opaque("type") @basic_alloc(opaque("type") %arg) {
+; CHECK-LABEL: @basic_alloc(
+; CHECK-NEXT:    ret opaque("type") [[ARG:%.*]]
+;
+  %val = alloca opaque("type")
+  store opaque("type") %arg, ptr %val
+  %ret = load opaque("type"), ptr %val
+  ret opaque("type") %ret
+}
+
+define opaque("type") @via_memcpy(opaque("type") %arg) {
+; CHECK-LABEL: @via_memcpy(
+; CHECK-NEXT:    ret opaque("type") [[ARG:%.*]]
+;
+  %val = alloca opaque("type")
+  %bar = alloca opaque("type")
+  store opaque("type") %arg, ptr %val
+  call void @llvm.memcpy.p0.p0.i64(ptr %bar, ptr %val, i64 8, i1 false)
+  %ret = load opaque("type"), ptr %bar
+  ret opaque("type") %ret
+}
+
+define opaque("type") @nobitcast(ptr %arg) {
+; CHECK-LABEL: @nobitcast(
+; CHECK-NEXT:    [[VAL:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    store ptr [[ARG:%.*]], ptr [[VAL]], align 8
+; CHECK-NEXT:    [[VAL_0_RET:%.*]] = load opaque("type"), ptr [[VAL]], align 8
+; CHECK-NEXT:    ret opaque("type") [[VAL_0_RET]]
+;
+  %val = alloca opaque("type")
+  store ptr %arg, ptr %val
+  %ret = load opaque("type"), ptr %val
+  ret opaque("type") %ret
+}
+
+define opaque("type") @viai64(opaque("type") %arg) {
+; CHECK-LABEL: @viai64(
+; CHECK-NEXT:    [[VAL:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    [[BAR:%.*]] = alloca opaque("type"), align 8
+; CHECK-NEXT:    store opaque("type") [[ARG:%.*]], ptr [[VAL]], align 8
+; CHECK-NEXT:    [[VAL_0_IMEMCPY:%.*]] = load i64, ptr [[VAL]], align 8
+; CHECK-NEXT:    store i64 [[VAL_0_IMEMCPY]], ptr [[BAR]], align 8
+; CHECK-NEXT:    [[BAR_0_RET:%.*]] = load opaque("type"), ptr [[BAR]], align 8
+; CHECK-NEXT:    ret opaque("type") [[BAR_0_RET]]
+;
+  %val = alloca opaque("type")
+  %bar = alloca opaque("type")
+  store opaque("type") %arg, ptr %val
+  %imemcpy = load i64, ptr %val
+  store i64 %imemcpy, ptr %bar
+  %ret = load opaque("type"), ptr %bar
+  ret opaque("type") %ret
+}
+
+declare void @llvm.memcpy.p0.p0.i64(ptr, ptr, i64, i1)

llvm/tools/llvm-c-test/echo.cpp

switch (Kind) {
       case LLVMMetadataTypeKind:
         return LLVMMetadataTypeInContext(Ctx);
       case LLVMX86_AMXTypeKind:
         return LLVMX86AMXTypeInContext(Ctx);
       case LLVMX86_MMXTypeKind:
         return LLVMX86MMXTypeInContext(Ctx);
       case LLVMTokenTypeKind:
         return LLVMTokenTypeInContext(Ctx);
+      case LLVMOpaqueTypeKind:
+        assert(false && "Implement me");
     }
 
     fprintf(stderr, "%d is not a supported typekind\n", Kind);
     exit(-1);
   }
 };
 
 static ValueMap clone_params(LLVMValueRef Src, LLVMValueRef Dst) {

llvm/unittests/IR/TypesTest.cpp

TEST(TypesTest, CopyPointerType) {
   PointerType *P2C = PointerType::getWithSamePointeeType(P2, 1);
   EXPECT_EQ(P2, P2C);
   EXPECT_FALSE(P2C->isOpaque());
   PointerType *P2C0 = PointerType::getWithSamePointeeType(P2, 0);
   EXPECT_NE(P2, P2C0);
   EXPECT_FALSE(P2C0->isOpaque());
 }
 
+TEST(TypesTest, OpaqueType) {
+  LLVMContext Context;
+  Type *A = OpaqueType::get(Context, "typea");
+  Type *Aparam = OpaqueType::get(Context, "typea", {}, {0, 1});
+  Type *Aparam2 = OpaqueType::get(Context, "typea", {}, {0, 1});
+  // Opaque types with same parameters are identical...
+  EXPECT_EQ(Aparam, Aparam2);
+  // ... but just having the same name is not enough.
+  EXPECT_NE(A, Aparam);
+}
+
 TEST(TypedPointerType, PrintTest) {
   std::string Buffer;
   LLVMContext Context;
   raw_string_ostream OS(Buffer);
 
   Type *I8Ptr = TypedPointerType::get(Type::getInt8Ty(Context), 0);
   I8Ptr->print(OS);
   EXPECT_EQ(StringRef(Buffer), ("typedptr(i8, 0)"));
 }
 
 }  // end anonymous namespace