[LLVMdev] RFC: Supporting different sized address space arithmetic

[Eli Friedman]

On Fri, Aug 17, 2012 at 2:53 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Currently LLVM only supports address calculations for a single address
> space(the default). This is problematic when the device pointer type is
> 32/64bits, but there are small distinct memories that only have 16 bits of
> addressing(think GPU's with small software controlled memory segments).
>
>
>
> I am proposing a modification to a few API's in SelectionDAG that I believe
> will fix this problem.
>
>
>
> In TargetLowering
>
> ·         Add getPointerTy to take an argument, the address space, this
> defaults to 0.
>
> ·         Add a virtual API call that returns the default address space for
> the target, this defaults to returning 0.

Under what circumstances would the default address space for a target not be 0?

> ·         Have the original getPointerTy implementation with no arguments
> query for the default address space.
>
> In SelectionDAG
>
> ·         Add a new API to getIntPtrConstant that takes an address space as
> the second argument

Do we actually need this API?  Normally, if you need a pointer-sized
constant, it means you have a value of pointer type somewhere nearby;
it's probably easier to just use the existing API which takes a
constant and a type than to try to dig the address space out of a
memory operation.

> ·         Modify the implementation of the original getIntPtrConstant
> function to call the new function with getDefaultAddressSpace().
>
> As far as I can tell, this should not affect any backends behavior, but will
> allow the targets with disjoint address spaces to directly address them in
> the most efficient manner.
>
>
>
> So, what do you think? Is this the correct approach? Or does it actually
> require more fundamental changes.

This is the right direction; I don't think you need anything else, at
least not in the SelectionDAG.

Are you planning on introducing an in-tree target that actually uses
this functionality?  I'm afraid it'll bitrot without good testing.

-Eli