search for: getdefaultaddressspac

...gt; > > > type, but on non-OpenCL systems, this behavior might not be > > > > warranted. > > > > > > > > Okay... that mostly makes sense. (Although it sounds like > > > > long-term, you'd want to eliminate all uses of > > > > getDefaultAddressSpace from target- independent code.) > > > > > > > > >> > * Have the original getPointerTy implementation with > > > > >> > no > > > > >> arguments > > > > >> > query for the default address space. >...

...nterTy 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 * Modify the implementation of the original getIntPtrConstant function to call the new function with getDefaultAddressSpace(). Modify SelectionDAGBuilder::visitGetElementPtr to get the address space of pointer argument and passing it into the getIntrPtrConstant and getPointerTy calls. As far as I can tell, this should not affect any backends behavior, but will allow the targets with disjoint address spaces to directl...

...utations the use the pointer > > > type, but on non-OpenCL systems, this behavior might not be > > > warranted. > > > > > > Okay... that mostly makes sense. (Although it sounds like > > > long-term, you'd want to eliminate all uses of > > > getDefaultAddressSpace from target- independent code.) > > > > > > >> > * Have the original getPointerTy implementation with > > > >> > no > > > >> arguments > > > >> > query for the default address space. > > > >> >...

...but on non-OpenCL > > > > > systems, this behavior might not be warranted. > > > > > > > > > > Okay... that mostly makes sense. (Although it sounds like > > > > > long-term, you'd want to eliminate all uses of > > > > > getDefaultAddressSpace from target- independent code.) > > > > > > > > > > >> > * Have the original getPointerTy implementation > > > > > >> > with no > > > > > >> arguments > > > > > >> > query for the de...

...change and break anything. Instead of changing all of the code to the new API, I leave the code alone and only change the locations that need the new functionality. > > > * 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 c...

...be the global address space > > for all computations the use the pointer type, but on non-OpenCL > > systems, this behavior might not be warranted. > > > > Okay... that mostly makes sense. (Although it sounds like long-term, > > you'd want to eliminate all uses of getDefaultAddressSpace from > > target- independent code.) > > > > >> > * Have the original getPointerTy implementation with no > > >> arguments > > >> > query for the default address space. > > >> > > > >> > In SelectionDAG >...

...nter 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 &gt...