[llvm-dev] Best way of implement a fat pointer for C
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 7 08:15:50 PST 2020
On 07/01/2020 16:00, Jie Zhou wrote:
>> LLVM does not assume that pointers are integers - we have done a lot of work to remove that assumption and the IR has always made the two types distinct. There are still a few rough areas, but these are bugs. We are able to compile nontrivial codebases (e.g. FreeBSD, WebKit) with optimisations enabled for targets where pointers and integers are distinct types at the hardware level.
> You’re correct that LLVM does not assume that pointers are integers. I think
> what I really tried to say in my previous email is that current LLVM implements
> PointerType as Integer and this gives me trouble in tons of places such as
> the memory layout for a pointer. In you experience, do you think it’s feasible
> to create a new llvm Type that inherits both llvm::PointerType and llvm::StructType
> and modify the bitcode generator to support this new type?
I don't think that this is something that would be maintainable long term.
For your use case, I would:
- Pick an address space to use for fat pointers.
- Define a DataLayout that has the correct size.
- In Clang, use that address space for any pointers you wish.
- Define intrinsics that get and set the various properties of the fat
- Define your calling convention to use a struct representation.
- Use addressspacecast for converting where needed.
At this point, you'll only use the struct representation across function
call boundaries. After inlining, run a pass that propagates the values
from get and set intrinsics and eliminates the addresspacecasts, so you
after inlining you are just using pointers in your address space.
Then you run whatever mid-level optimisations you want (probably the
standard clang set).
Late, run a pass that transforms pointers in that address space into
pointers in AS0 (this is now a function-local transform) along with the
Finally, run any passes you need to hoist checks out of loops.
More information about the llvm-dev