[LLVMdev] Address space extension

[Pete Cooper]

James, I think what you're proposing is a very good idea.

My original metadata suggestion demonstrated a memory space hierarchy which was supposed to be similar in design and use to the tbaa metadata. 

It's clear that more than just a hierarchy is needed and I think what you've proposed is a better way at solving the problem.

Thanks
Pete

Sent from my iPhone

> On Aug 9, 2013, at 2:27 AM, James Courtier-Dutton <james.dutton at gmail.com> wrote:
> 
>> On 8 August 2013 21:29, Eric Christopher <echristo at gmail.com> wrote:
>> On Thu, Aug 8, 2013 at 1:26 PM, Michele Scandale
>> <michele.scandale at gmail.com> wrote:
>>> On 08/08/2013 09:59 PM, Eric Christopher wrote:
>>>> 
>>>> I don't believe so, no. Metadata should not be required for correct
>>>> program behavior. It can be necessary for fast program behavior, but
>>>> not for correct. The IR level handles the proper semantics of the
>>>> program, metadata can provide extra optimization information. As an
>>>> example see the TBAA work that was done.
>>>> 
>>>> -eric
>>> 
>>> 
>>> Perfectly fine with this. My question was ignoring the implementation detail
>>> (the use of metadata to represent mapping infos).
>>> 
>>> I think that the mapping should be a requirement for the correctness, so I
>>> think we need another way to represent this...
>>> 
>>> What is your opinion on this?
>> 
>> Wish I had one here. I completely defer to Chris for any IR design
>> issues here. I just wanted to make sure that you didn't waste time
>> going down the metadata for correctness path. :)
> 
> A suggestion:
> Define/describe each address space in the lower layer of LLVM. <- all
> the target specific info.
> E.g. Address space 0 is 64bits and needs specific instructions to access it.
> The LLVM IR can query the lower layer when it needs to know a
> description of address space 0 during an optimization step.
> CLANG then queries LLVM for address space description when it needs it.
> From the description, LLVM IR or CLANG then make their own choices:
> E.g. CLANG decides for itself if, based on the address space
> description, address space 0 is local, private or global.
> The description of each address space would need to cover all the
> different types of address space there are in enough detail. I.e. Not
> just the bitsize, but also whether pointers can be converted from one
> address space to another or not, and if so, how.
> One advantage of this approach is that the "CLANG deciding for itself
> whether address space 0 is local, private or global" only needs to
> happen once, instead of needing to process it every time the metadata
> appears (if it was stored in metadata instead).
> This also might help, by allowing target specific master description
> to be located in just one place, and all components, CLANG and LLVM
> use that information.
> 
> James
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev