[LLVMdev] Address space extension

[Justin Holewinski]

On Wed, Aug 7, 2013 at 7:45 PM, Michele Scandale <michele.scandale at gmail.com
> wrote:

> On 08/08/2013 01:36 AM, Justin Holewinski wrote:
>
>> It's not clear to me how this would work for targets that use the same
>> physical address space for multiple language-specific address spaces.
>>   If a target maps both constant and global to address space 42 (for
>> example), how would the optimizer differentiate between these two?
>>
>>
> I think that the proposal of Pete would imply that in the IR the logical
> address spaces are represented with addrspace modifier (3 for constant and
> 1 for global) so the optimizer can distinguish the two and using "address
> space metadata" can derive properties related to this address spaces.
> During the instruction selection the mapping information are used to drive
> the selection phase.
>
> IMO whenever possible both address spaces informations must be maintained.
>

This worries me a bit.  This would introduce language-specific processing
into SelectionDAG.  OpenCL maps address spaces one way, other languages map
them in other ways.  Currently, it is the job of the front-end to map
pointers into the correct address space for the target (hence the address
space map in clang).  With (my understanding of) this proposal, there would
be a pre-defined set of language-specific address spaces that the target
would need to know about. IMO it should be the job of the front-end to do
this mapping.


>
>> On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale
>> <michele.scandale at gmail.com <mailto:michele.scandale@**gmail.com<michele.scandale at gmail.com>>>
>> wrote:
>>
>>     On 08/08/2013 12:55 AM, Matt Arsenault wrote:
>>
>>         On 08/07/2013 03:52 PM, Michele Scandale wrote:
>>
>>
>>             In the opencl specification is said that the four address
>>             spaces are
>>             disjoint, so my conclusion of non aliasing with the others.
>>
>>         In OpenCL 2.0, you can cast between the generic address space and
>>         global/local/private, so there's also that to consider.
>>
>>     Thanks for correction. My reference was the opencl 1.2 specification.
>>
>>     Considering the case of OpenCL 2.0 IMO we would have another address
>>     space that contains the private, the global and the local address
>>     spaces.
>>
>>
>>     -Michele
>>
>>     ______________________________**___________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev>
>>
>>     <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Justin Holewinski
>>
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130807/78e85609/attachment.html>