On targets like AMDGPU where stack variables have a default address space, we need to be careful that the address of operator returns a pointer of the expected type (rather than blindly passing back the pointer it gets as the address).
This means that a stack variable x in AMDGPU will live in address space 5, but when we do &x we return a pointer with address space 0 (i.e., a generic pointer). This requires an addrspacecast in the Terra backend.
One might wonder whether it would be better to make &x return terralib.types.pointer(int, 5) (i.e., pointer to addrspace 5), but if we did this Terra functions would become target-specific. It would be impossible to even type check a function without having the target defined. So I think the only sensible approach is to make & return the generic addrspace and then cast it in the backend.
If it really becomes a problem down the road we may need to make a terralib.addressof(x, 5) operator to allow the user to specify the address space the pointer should be placed into.
On targets like AMDGPU where stack variables have a default address space, we need to be careful that the address of operator returns a pointer of the expected type (rather than blindly passing back the pointer it gets as the address).
This means that a stack variable
xin AMDGPU will live in address space5, but when we do&xwe return a pointer with address space0(i.e., a generic pointer). This requires anaddrspacecastin the Terra backend.One might wonder whether it would be better to make
&xreturnterralib.types.pointer(int, 5)(i.e., pointer to addrspace5), but if we did this Terra functions would become target-specific. It would be impossible to even type check a function without having the target defined. So I think the only sensible approach is to make&return the generic addrspace and then cast it in the backend.If it really becomes a problem down the road we may need to make a
terralib.addressof(x, 5)operator to allow the user to specify the address space the pointer should be placed into.