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

Thu Jul 13 10:33:50 PDT 2017

On 07/13/2017 12:25 PM, Björn Pettersson A wrote:
>
>> -----Original Message-----
>> From: Hal Finkel [mailto:hfinkel at anl.gov]
>> Sent: den 13 juli 2017 16:01
>> To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall
>> <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io>
>> Cc: 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 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.
> My point was that the DataLayout isn't available inside the LLParser and the BitcodeReader, up until the point when it has been parsed. So I would not say "always available".
>
> Both LLParser and BitcodeReader is for example using getAddressSpace(), both directly and maybe also indirectly through different interfaces (perhaps not on function pointers though). My concern is that maybe the incorrect address space will be used while parsing, and then it might be hard to find all places to fixup at a later stage. when having parsed the DataLayout and finding out what the default address space really is.
> Or if there is some undocumented(?) rule that the DataLayout always comes before function declarations in the ll/bc file, then all functions can get the default address space attribute directly (as indicated by the DataLayout) when being parsed.
>
> I think the whole idea from Dylan was to do this as a fixup after LLParser/BitcodeReader. I.e not trying to lookup a functions address space already when parsing the function declaration. So then the rule would be - do not use Pointer<Function>::getAddressSpace(), or PointerType::get() etc. during ll/bc parsing because it might give the wrong result. Maybe it is possible to assert on that?
>
> We could of course give functions some kind of undefined address space value when parsing ll/bc and adding functions to the symbol table. That might help us catch situations when someone tries to fetch the address space for a function pointer before the set-default-address-space-as-given-by-datalayout-on-all-functions pass has executed.

I understand your point. We need to extend the syntax to enabling 
tagging functions with addressspaces directly (i.e. as a function 
attribute). DataLayout can't, as you noted, and shouldn't, be used to 
adjust defaults during parsing. The point of the defaults in DataLayout 
is to provide some way to supply correct defaults should optimizations 
need them.

  -Hal

>
>> (*) 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

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