search for: globalconst

...sence on a GlobalObject would also imply > that the address of the GlobalObject is "fixed" at link time. > > Going back to IR-level representation: here is an alternative > representation based on a suggestion from Eli. > > Introduce a new type of GlobalValue called GlobalConstant. > GlobalConstant would fit into the GlobalValue hierarchy like this: > > * GlobalValue > o GlobalConstant > o GlobalPointer > + GlobalIndirectSymbol > # GlobalAlias > # GlobalIFunc > + GlobalObject >...

...it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. > > Going back to IR-level representation: here is an alternative representation based on a suggestion from Eli. > > Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant would fit into the GlobalValue hierarchy like this: > GlobalValue > GlobalConstant > GlobalPointer > GlobalIndirectSymbol > GlobalAlias > GlobalIFunc > GlobalObject > Function > GlobalVariable > GlobalValue would no longer be assumed to be of pointer...

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 GlobalVar...

...e on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. >> >> Going back to IR-level representation: here is an alternative representation based on a suggestion from Eli. >> >> Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant would fit into the GlobalValue hierarchy like this: >> GlobalValue >> GlobalConstant >> GlobalPointer >> GlobalIndirectSymbol >> GlobalAlias >> GlobalIFunc >> GlobalObject >> Function >> GlobalVariable >> GlobalValue wou...

...it, we may as well use the same construct to define it. > > I guess the only issue then is that the current implementation of > alias becomes even more needlessly generic :-( > > Cheers, > Rafael > 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...

Hi all, I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation. Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions

> You get the code you want with > > @foo = external hidden global i8 > > or > > @foo = external protected global i8 Sorry, not quiet. What you get is leaq foo(%rip), %rax Since it is still assuming foo is a position in the file. So yes, we need a way to declare an absolute value. If we can declare it, we may as well use the same construct to define it. I guess the

...so imply that the address of the >>> GlobalObject is "fixed" at link time. >> >> >> Going back to IR-level representation: here is an alternative >> representation based on a suggestion from Eli. >> >> Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant >> would fit into the GlobalValue hierarchy like this: >> >> GlobalValue >> >> GlobalConstant >> GlobalPointer >> >> GlobalIndirectSymbol >> >> GlobalAlias >> GlobalIFunc >> >> GlobalObject >> &gt...

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...

On Tue, Oct 25, 2016 at 5:49 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > >>> @foo = globalconst i32 42 > >>> > >>> > >>> This is equivalent to writing "foo = 42" in assembly? > >> > >> > >> Yes. > > > > > > Back in the day the idea was to use an alias whose ConstantExpr was > > just 42. Would that...

...both of your emails in one, sorry for the delay: > > On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > I think there are a couple of additional considerations we should make > here: > > - What are we trying to model? To me it's clear that GlobalConstant is > for modelling integers, not pointers. That alone may not necessarily be > enough to motivate a representational change, but… > > I understand where you’re coming from, but I think we’re modeling three > different things, and disagreeing about how to clump them together....

...xorl %eax, %eax retq The appropriate representation for this at the IR level is the subject of the RFC entitled 'Absolute or "fixed address" symbols as immediate operands'. We can imagine, though, that it could look something like this: @__typeid_typeid3_rotate_count = external globalconst i8 @__typeid_typeid3_size = external globalconst i32 @__typeid_typeid3_bit_mask = external globalconst i8 @__typeid_typeid3_byte_array = external global i8 @__typeid_typeid3_global_addr = external global i8 define i1 @baz(i32* %p) { %pi8 = bitcast i32* %p to i8* %1 = ptrtoint i8* %pi8 to i32...

...gt; The appropriate representation for this at the IR level is the subject of > the RFC entitled 'Absolute or "fixed address" symbols as immediate > operands'. We can imagine, though, that it could look something like this: > > @__typeid_typeid3_rotate_count = external globalconst i8 > @__typeid_typeid3_size = external globalconst i32 > @__typeid_typeid3_bit_mask = external globalconst i8 > @__typeid_typeid3_byte_array = external global i8 > @__typeid_typeid3_global_addr = external global i8 > Naive question: These will be defined in the object file containin...

Responding to both of your emails in one, sorry for the delay: > On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > I think there are a couple of additional considerations we should make here: > What are we trying to model? To me it's clear that GlobalConstant is for modelling integers, not pointers. That alone may not necessarily be enough to motivate a representational change, but… I understand where you’re coming from, but I think we’re modeling three different things, and disagreeing about how to clump them together. The three things I see in fli...

...y for the delay: > >> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >> I think there are a couple of additional considerations we should make here: >> What are we trying to model? To me it's clear that GlobalConstant is for modelling integers, not pointers. That alone may not necessarily be enough to motivate a representational change, but… > I understand where you’re coming from, but I think we’re modeling three different things, and disagreeing about how to clump them together. The three things I see i...

...for the delay: >> >> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> I think there are a couple of additional considerations we should make >> here: >> >> - What are we trying to model? To me it's clear that GlobalConstant >> is for modelling integers, not pointers. That alone may not necessarily be >> enough to motivate a representational change, but… >> >> I understand where you’re coming from, but I think we’re modeling three >> different things, and disagreeing about how to...

...oday we select: addfoo: addq foo at GOTPCREL(%rip), %rdi movq %rdi, %rax retq We could use attributes to try to convince ISel not to form GlobalAddress nodes, but we might also want to consider just adding a new kind of global. Chris's proposal of giving this new globalconst pointer type seems like a reasonable compromise to avoid disturbing the rest of LLVM. The ptrtoint cast will go away when we build MI. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/6b909004/attachmen...

On 2007-11-26, at 21:12, Jon Harrop wrote: > Provide a type enumerating the valid terminators and restrict the > last instruction in a block to be a terminator. Something like this: > > type terminator = [ `ret of llvalue | `br of llvalue ] > type instruction = > [ terminator > | `add of llvalue * llvalue > | `sub of llvalue * llvalue ] > type block