[LLVMdev] Moving towards a singular pointer type
Reid Kleckner
rnk at google.com
Fri Feb 6 18:09:12 PST 2015
I think we should keep GEP essentially the same, but disassociate the type
being GEPd over from the type of the operands. So, assuming the new ptr
type is spelled "ptr", we could use this syntax:
%inner.ptr = getelementptr ptr, ptr %x, i32 1
Or if I was adding 1 to a "struct A*" value in C:
%next_elt = getelementptr %struct.A, ptr %x, i32 1
Ditto for all other instructions that care about pointee types, like load
and store:
%v = load i32, ptr %p ; loads already know (and store!) their loaded type
internally
store i32 %v, ptr %p ; no need to duplicate that %p points to, we have the
type on %v
I don't think this can be incremental, I think it all goes at once. I think
you might need to add a new GEP bitcode opcode, since that instruction
grows a new type operand that doesn't come from an operand type or result
type. It also wouldn't be too hard to accept the old .ll syntax, since the
upgrade path mostly discards information.
On Fri, Feb 6, 2015 at 4:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:
> How would GEP's look like in this scheme? Concretely, what would be
> the equivalent of
>
> %inner.ptr = getelementptr i8** %x, i32 1
>
> assuming we're doing target independent optimizations and do not know
> the size of a pointer?
>
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150206/dd1f9b84/attachment.html>
More information about the llvm-dev
mailing list