[PATCH] Globals in non-zero address spaces might be null

[Pete Cooper via llvm-commits]

Sent from my iPhone

> On Aug 26, 2015, at 8:23 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> 
>> On Aug 26, 2015, at 4:44 PM, Pete Cooper <peter_cooper at apple.com> wrote:
>> 
>> Hi Philip
>> 
>> This is an offshoot of the conversation we had here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150824/295815.html
>> 
>> The attached patch make sure that we only add nonnull attributes to globals in address space 0.  Other address spaces may or may not permit a global to live at address 0, but we have to assume that they might.
> 
> Isn’t something that should be target configurable? Any reason for not having TTI with a default behavior which would be the current one, but that targets could customize?
I totally agree that it should be configurable, but actually i think it needs to be the frontend (via IR, eg global metadata) not the target that describes this.

As an example of why, consider open cl on x86. Say globals are in address space 1 in the language itself, right now the front end has to map that to address space 0 when it generates the IR. This is because the x86 backend doesn't have distinct memory/instructions to access address space 1. It's a language feature not a HW feature.

Now you could bake this in to the backend and use TTI, but you'd have to do this for each backend/language configuration. So maybe you say that address space 1 on x86 always means CL globals, but what if you don't also reserve the same address space on arm for the same reason. Maybe arm needs to use address space 2 for CL globals because hsail got address space 1 for its globals. And so on.

So personally I feel that we need a way for the front end to describe what it meant when it generated an address space. Did it mean that this address space was for globals/locals/constants/etc. What properties of each of those address spaces did it assume existed when it created them, and as such it wants the IR optimiser to adhere to too. This is similar to how the front end has to tell the optimiser about tbaa because only it knows what the types actually meant and how they can alias.

Now such a picture doesn't solve the problem of how to map from the logical frontend/IR spaces to the HW ones, but a simple solution would be to allow the front end to also describe the mapping to the IR along with other properties (on x86 everything maps to 0 in instruction selection for example). As a bonus, if you're describing address spaces anyway, you can also describe when they do/don't overlap and so address space alias analysis becomes extremely easy to implement in a portable way.

Pete
> 
> — 
> Mehdi
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150826/6872fd36/attachment.html>