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

[Björn Pettersson A via llvm-dev]

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?

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.

/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