[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands

[Peter Collingbourne via llvm-dev]

On Wed, Oct 26, 2016 at 9:21 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 26 October 2016 at 12:14, Reid Kleckner <rnk at google.com> wrote:
> > On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at pcc.me.uk>
> > wrote:
> >>
> >> So, to summarise the overall consensus on this thread:
> >> - We should introduce a GlobalConstant class which supports definitions
> >> and declarations
> >> - It should derive from GlobalValue
> >> - No type changes for GlobalValue (i.e. still required to be pointer
> type)
> >> - To communicate the range we should use !range metadata and support it
> on
> >> GlobalConstant as well as GlobalVariable
> >>
> >> Although I am not convinced that this is the right representation I
> appear
> >> to be in the minority here, so if this seems reasonable to folks I will
> go
> >> ahead and implement it.
> >
> >
> > I could go either way on GlobalConstant being a pointer or not. Keeping
> the
> > "globals are points" invariant is nice, but making LLVM IR more
> accurately
> > model object file formats is also good.
>
> I would say that requiring a pointer type, specially when there is
> only one pointer type in the future, is closer to what the object
> format is. In ELF you will get an st_value regardless of it being
> absolute of a position in the file. It doesn't really make sense to
> have a type that is not at least pointer sized.
>

Acknowledged but that seems a little like saying that because some
architectures only have pointer sized registers we should only support
pointers and pointer sized integers on those architectures.

(Also it appears that COFF's equivalent of st_value is 32-bit even on
64-bit architectures.)

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/ece9ab9b/attachment.html>