[llvm-dev] RFC: Harvard architectures and default address spaces

[Hal Finkel via llvm-dev]

On 07/13/2017 05:38 AM, Björn Pettersson A via llvm-dev wrote:
> My experience of having the address space for functions (or function pointers) in the DataLayout i that when the .ll file is parsed we need to parse the DataLayout before any function declarations. That is needed because we want to attribute the functions with correct address space (according to DataLayout) when inserting them in the symbol table. An alternative would be to update address space info for functions after having parsed the DataLayout.
>
> Is the DataLayout normally used when parsing the .ll file (or .bc)? Or would this be the first case of doing that?
>
> Is it guaranteed that DataLayout is specified/parsed before function declaration, or that the DataLayout specification is context sensitive and only is valid for the following declarations?

The DataLayout is a required part of the .ll/.bc file. In the .ll file 
(*), it's the part of the module that looks like this:

   target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

it is global to the entire module and always available.

(*) It is true that you can write tests without specifying one of these, 
but in such cases, you just get the builtin default. For all real cases 
you'll need to have a target-appropriate DataLayout string.

>
> What if there are several address spaces for functions? Or is that a silly thing that no one ever will use? Having the address space specified in the DataLayout would be insufficient, since we would need to attribute the functions separately, right?
>
> I do not say that having the info in the DataLayout is a totally bad idea (since our out-of-tree target is using that trick), but I think it might impose some problems as well. And perhaps it isn't the most general solution.

If different functions might be in different address spaces, you'll need 
some other mechanism to set the address space (as a single default won't 
suffice). You might use source-level function attributes, for example.

  -Hal

>
> /Björn
>
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David
>> Chisnall via llvm-dev
>> Sent: den 12 juli 2017 17:26
>> To: Dylan McKay <me at dylanmckay.io>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Carl Peto <carl.peto at me.com>
>> Subject: Re: [llvm-dev] RFC: Harvard architectures and default address
>> spaces
>>
>> On 11 Jul 2017, at 23:18, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org>
>> wrote:
>>>> Add this information to DataLayout and to use that information in
>> relevant places.
>>> This sounds like a much better/cleaner idea, thanks!
>> I’d suggest taking a look at the alloca address space changes, which were
>> recently added based on a cleaned-up version of our code.  We have a similar
>> issue (function and data pointers have the same representation for us, but
>> casting requires different handling[1]) and have considered adding address
>> spaces to functions.
>>
>> David
>>
>> [1] Probably not relevant for this discussion, but if anyone cares: in our world
>> we have 128-bit fat pointers contain base, bounds and permissions, and that
>> 64-bit pointers that are implicitly relative to one of two special fat pointer
>> registers, one for code and one for data.  We must therefore handle 64-bit to
>> 128-bit pointer casts differently depending on whether we’re casting code or
>> data pointers.  We currently do this with some fairly ugly hacks, but being
>> able to put all functions in a different AS would make this much easier for us.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory