[PATCH] D127728: [BitcodeReader] Allow reading pointer types from old IR

[Sebastian Neubauer via Phabricator via llvm-commits]

sebastian-ne added a comment.

> I think exposing something like this is reasonable.

That’s encouraging, thanks for the feedback.

> My high-level question would be whether function signatures are the only place where this is needed or whether we would benefit from a more generic mechanism -- for example, does a similar use-case for calls exist?

Good point. As far as I know, dxil does not use indirect calls, so one can always do `CallInst->getCalledFunction()` and get types from the function signature.
I’ll try to get some opaque pointer support into our existing software to see if there’s more needed.

To allow extending the callback (potentially later), we could give the lambda a `Value` instead of a `Function`?

> Might a more general annotation in the IR make sense, then the bitcode reader could annotate the module with type information which would persist after the module is created.

The `elementtype(<ty>)` attribute on function arguments sounded sounds quite fitting as a general annotation. It’s explicitly restricted to intrinsics though.
I think there’s more problems than preserving type information. As far as I understand, the SPIR-V backend wants to compile things like C code, which allows pointers and union casts, but I think SPIR-V and DXIL both don’t allow to re-interpret memory, so not sure how that’s handled at all.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127728/new/

https://reviews.llvm.org/D127728