[llvm-dev] Best way of implement a fat pointer for C
Jie Zhou via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 7 08:00:01 PST 2020
> On Jan 7, 2020, at 06:51, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> For CHERI, we use pointers in address space 200 to represent memory capabilities (which are a kind of fat pointer). These are able to pass through the LLVM pipeline and we then lower them to special instructions in the various targets that understand that pointers are a heardware-enforced type. It would be possible to add late pass that then expanded these into a StructType that contained the address and whatever metadata you wanted, and expanded loads and stores to use the address component. Note that if you want to hoist checks out of loops, you will want to do this expansion somewhere in the middle of your pass pipeline.
> The tricky part here is in function parameters: you cannot easily change the type of a function after it has been created. Your best bet here is to always pass fat pointers as the structure representation.
Yes passing pointers thorough function parameters and return values is tricky;
I got yelled at by the compiler when I tried to use llvm::Value::mutateType()
to change the prototype of a function. :-)
> 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?
> On 07/01/2020 02:45, Jie Zhou via llvm-dev wrote:
>> Dear All,
>> I’m working on a project that extends C. I’m adding a new type of pointer
>> that is a fat pointer. It has some metadata about the pointed object besides
>> the starting address of the object. Currently I implemented this pointer as
>> an llvm:StructType. In llvm::Type generation function
>> /llvm::Type *CodeGenTypes::ConvertType(QualType T)/
>> in the case for /clang::Type::Pointer/, instead of creating an llvm::PointerType
>> I create an llvm::StructType type for this new type of pointer. And I added some
>> helper code in llvm::StructType and in multiple places I added code to trick
>> the compiler to believe sometimes a struct is actually a pointer. Until now
>> it compile test programs fine with -O0 but I got lots of assertion failures when
>> compiling with -O1 or -O2 majorly because of the confusion of type mismatch.
>> LLVM assumes that a PointerType is essentially an Integer (32 or 64 bit depending
>> on the architecture), and since this is quite a fundamental assumption, I started
>> to question whether my way of implementing the fat pointer is feasible.
>> I thought about adding a new llvm type that inherits both llvm:PointerType
>> and llvm:StructType; but I’m not sure if this is the correct path. It looks like
>> this demands substantial changes to the compiler including adding code
>> for bitcode generation. Can you give me some advice on how to implement
>> a fat pointer in llvm?
>> - Jie
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev