TODO: need to support opaque pointers

[vtjnash]

Supporting opaque pointers will be a bit of a major design effort, and require a mini inference step to recover "best" types and tracking where to insert casts.

[hikari-no-yume]

This would be easier to do if we had an intermediate representation within the backend. It would be helpful for other things too (not producing redundant parentheses and other type casts for example).

[python3kgae]

We have PointerTypeAnalysis for DirectX backend to help recover the element type from opaque pointer.
Will it be useful here?
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/DirectX/PointerTypeAnalysis.cpp

[vtjnash]

alloca still has types, and otherwise void* is equivalent, so it likely shouldn't be necessary. But someone needs to put in the effort to handle it

[python3kgae]

Yes, void * should work for all cases.
Global variables have types too. But function parameter will need analysis to get pointer element type.

Off the topic, any plan for update to llvm 15?

[vtjnash]

In particular though, C defines cast to/from void* to be implicit (unlike C++), so we can likely just drop the types and use void instead, except when they are actually relevant to the operation (load, store, GEP, and alloca), just like opaque pointers in LLVM.

[hikari-no-yume]

We might need to be careful in which types we pick in order to avoid undefined behaviour issues with C's aliasing rules? I'm not sure…

[vtjnash]

Yeah, to be extra pedantic, we should only ever use memcpy into a temporary buffer, instead of direct load and store on pointers. Currently we assume users will pass -fno-strict-aliasing to their compiler

[vtjnash]

Of note however, the intermediate types assigned to the pointee are of no relevance to that part of the C standard, only the type used for the load or store itself.

[hikari-no-yume]

Yeah I guess it's an existing issue and nothing is really changed by the switch to opaque types in LLVM.

[dpaoliello]

Of note however, the intermediate types assigned to the pointee are of no relevance to that part of the C standard, only the type used for the load or store itself.

I was just about to say this.

So far, the only place that I can't get to the actual type seems to be for return types and parameters in functions: I'm going to try using a modified version of the DirectX PointerTypeAnalysis to determine the types (the current analysis code loses the number of indirections, so I'll need to fork it to add in tracking for that) - unless folks are ok with all function signatures only using void* (which might be fine?).

[vtjnash]

I am happy with void* there. It is hardly the worst issue we have with function signatures (which would actually require a whole custom clang::TargetInfo to get the ABI mangling correct)