This is an archive of the discontinued LLVM Phabricator instance.

[IR] Move support for dxil::TypedPointerType to LLVM core IR.
ClosedPublic

Authored by jcranmer-intel on Jul 26 2022, 11:30 AM.

Details

Summary

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).

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJul 26 2022, 11:30 AM
jcranmer-intel requested review of this revision.Jul 26 2022, 11:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 26 2022, 11:30 AM

Dropping LLVMContext target-specific data, originally added for this feature.

nikic accepted this revision.Jul 27 2022, 12:47 AM
nikic added a reviewer: aeubanks.
nikic added a subscriber: aeubanks.

LG from my side, but I'd like @aeubanks to confirm that he's fine with this as well.

llvm/lib/IR/LLVMContextImpl.h
41

This can be a forward-declare.

llvm/lib/IR/TypedPointerType.cpp
17

Class no longer needed?

This revision is now accepted and ready to land.Jul 27 2022, 12:47 AM
nikic added inline comments.Jul 27 2022, 12:49 AM
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.

Update for review coments.

jcranmer-intel marked 2 inline comments as done.

Typo fix.

nikic added inline comments.Jul 27 2022, 7:50 AM
llvm/lib/IR/AsmWriter.cpp
615

I believe this is missing an *, you're currently printing the address of the element type.

jcranmer-intel marked 2 inline comments as done.Jul 27 2022, 7:54 AM
jcranmer-intel added inline comments.
llvm/lib/IR/AsmWriter.cpp
615

Just noticed it right before you wrote that comment, I'm embarrassed to have not caught it earlier. :-(

beanz added inline comments.Jul 27 2022, 8:39 AM
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.

beanz added inline comments.Jul 27 2022, 9:11 AM
llvm/lib/Target/DirectX/DXILWriter/DXILValueEnumerator.cpp
376

This needs to drop the dxil namespace.

397

Here too.

jcranmer-intel marked an inline comment as done.

Fix DirectX build.

Also took the opportunity to fix the printing of typed pointer slightly.

jcranmer-intel marked 3 inline comments as done.Jul 27 2022, 12:10 PM

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

beanz added a comment.Jul 27 2022, 5:26 PM

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*.

beanz accepted this revision.Jul 27 2022, 5:26 PM

With the latest updates this LGTM.

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?

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.

Friendly review ping, @aeubanks ?

beanz added a comment.Aug 3 2022, 7:59 AM

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.

aeubanks accepted this revision.Aug 3 2022, 8:14 AM

sorry, I'd said that this change looks fine but didn't explicitly accept

This revision was landed with ongoing or failed builds.Aug 4 2022, 7:42 AM
This revision was automatically updated to reflect the committed changes.