In the out-of-tree CHERI and Arm Morello backends pointers are 128 or 64
bits, but only 64/32 bits of those hold the address information (our
DataLayout strings use "-pf200:128:128:128:64"/"-pf200:64:64:64:32").
I recently merged https://reviews.llvm.org/D73131 and started seeing
assertions in various tests due to this i8 addrspace(200)* -> i128
ptrtoint.
Details
- Reviewers
lebedev.ri nikic jdoerfert
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It's not really clear why using the index type for this would be correct. The index type is used for GEP index and casting a pointer to the index type doesn't make a whole lot of sense to me. Do you have any LangRef wording or other usages that would show that this is a sensible thing to do?
+1, i'm not convinced that index type is the right fix here.
I would think that you need to either unbreak the invariant that decltype(sizeof(ptr))==intptrtype
or make that addressspace non-integral, thus preventing int<->ptr casts.
We use something similar to non-integral pointers, but our fork pre-dates that work so we use DL.isFatPointer() instead.
I have been meaning make use of the non-integral pointer work for a long time but it's too strict for our purposes:
For CHERI pointers, inttoptr should be avoided, but ptrtoint is perfectly fine (you just get the address part and not the additional metadata).
My understanding of D42123 was that the index width is the number of bits that are affected by pointer arithmetic (i.e. the range of the pointer, 64 bits for our 128-bit capabilities).
If you disagree with that interpretation I guess I can to add another DataLayout field to pointer types that specifies the address range?