This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR--the type is intended
to remain an auxiliary type, not a real LLVM type. So no support is provided for
LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make
Type->dump() work properly).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/IR/AsmWriter.cpp | ||
---|---|---|
615 | If it's useful for debugging, you could also include TypedPointerType.h here and print *cast<TypedPointerType>(Ty->getElementType()), instead of printing the address of the type. |
llvm/lib/IR/AsmWriter.cpp | ||
---|---|---|
615 | I believe this is missing an *, you're currently printing the address of the element type. |
llvm/lib/IR/AsmWriter.cpp | ||
---|---|---|
615 | Just noticed it right before you wrote that comment, I'm embarrassed to have not caught it earlier. :-( |
llvm/unittests/Target/DirectX/PointerTypeAnalysisTests.cpp | ||
---|---|---|
29–30 | This test case can be moved out of the DirectX tests into IR tests, so that it gets run even if you don't compile in the DirectX backend. |
Fix DirectX build.
Also took the opportunity to fix the printing of typed pointer slightly.
sorry, I haven't really been following https://discourse.llvm.org/t/rfc-better-support-for-typed-pointers-in-an-opaque-pointer-world, I'm reading through it
this change seems fine
but looking at PointerTypeAnalysis::run, if I'm understanding correctly, the pointee type can change based on optimizations. e.g. with a load i32, ptr %p the pointee type is i32, but if that load is eliminated and there are no users of the pointer, its pointee type is i8. and I believe this currently makes it into the generated DXIL. is this an issue? I'd assume so since the idea to use i8* everywhere doesn't seem to be the direction we're going
DXIL is LLVM 3.7 bitcode, so opaque pointers don’t exist. i8* if we can’t figure out a pointer type is the closest we get to void*.
I mean, is it okay if a pointer parameter can either be inferred and written as i8* or i32* depending on optimizations?
The question of pointer parameters is I think orthogonal to the change here. I can't speak for DXIL in particular, but for SPIR-V, there can sometimes be repercussions. We have some ideas for how to get the types of parameters inferred correctly, with the leading candidate at present being recovering information from Itanium mangled names.
Just to add context. From the DXIL perspective, we don't really have dynamic linking. We will probably need to do something to preserve parameter types for static linking, but since static linking operates on IR, we can probably manage that without too much trouble.
The ins and outs of pointer type re-materialization is probably a bit out of scope for this review, but the DXIL pass is _way_ far from being production ready. It is really more of a proof-of-concept than anything else. I believe @jcranmer-intel, has a more comprehensive pass in development, and we'll hopefully converge to a single implementation. This change is part of making that possible by moving sharable logic into the IR library.
If it's useful for debugging, you could also include TypedPointerType.h here and print *cast<TypedPointerType>(Ty->getElementType()), instead of printing the address of the type.