search for: globalconstant

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

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

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

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

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

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

...at we can already use aliases for definitions -- that's what I've been using in my prototype. What I think we need to decide on here is a representation for declarations. From that, I think our representation for definitions should be clear. For example, I think that if we decide to require GlobalConstant to have a pointer type, it may be reasonable to use it only for declarations and to use GlobalAlias for definitions. This I think would be analogous to the current state where a GlobalAlias can be referenced by either a Function or a GlobalVariable. Thanks, -- -- Peter -------------- next part -...

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

Hi all, As promised, here is a brain dump on how I see CFI for vcalls working under ThinLTO. Most of this has been prototyped, so the design does appear to be sound. For context on how CFI currently works under regular LTO, please read: http://llvm.org/docs/TypeMetadata.html http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html http://clang.llvm.org/docs/LTOVisibility.html ==== Summary

Hi Peter, Thanks for sending this and sorry for the slow response. Some questions below. Teresa On Tue, Oct 25, 2016 at 5:27 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > > As promised, here is a brain dump on how I see CFI for vcalls working > under ThinLTO. Most of this has been prototyped, so the design does appear > to be sound. For context on how CFI

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

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

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

On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. > No, the value will be discovered at link time, but we want instruction selection to treat the symbol as an immediate, not a GlobalAddress that will

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