similar to: [IR] Modelling of GlobalIFunc

> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. I still don't understand how it can happen looking to the code ( https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). I don't have a strong opinion here because deriving

> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: > The specific change I have in mind is to allow !range metadata on GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the

> On Oct 25, 2016, at 9:09 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Oct 24, 2016 at 10:48 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote:

On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk > <mailto:peter at pcc.me.uk>> wrote: > > The specific change I have in mind is to allow !range metadata on > GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the >

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui > Song via llvm-dev > Sent: Thursday, August 20, 2020 10:18 PM > To: Leonard Chan <leonardchan at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT

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

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

On 24 October 2016 at 16:54, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: >> >> On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: >> >> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk> >>

Hi, I just spent 4 hours trying to find a way to get the name of the resolver function of a ifunc definition ... :-( and with all that time I didnt event get far: for (GlobalIFunc &IF : M.ifuncs()) { StringRef ifunc_name = IF.getName(); Constant *r = IF.getResolver(); But how do I get to the (Function*) or function name of the resolver from there? I tried everything with the Constant

On Fri, May 23, 2014 at 3:06 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > > Sent from my iPhone > >> On May 23, 2014, at 17:51, Eric Christopher <echristo at gmail.com> wrote: >> >> I'm not there yet, but at some point I'm going to need the notion of a >> global callable function like symbol that's resolved at

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

Hi Everyone, I would like to implement GCC ifunc attribute support in Clang and LLVM. At the moment Clang ignores the attribute with a warning. On LLVM IR level there is no support for ifunc. But there is some support for ELF symbol type `@gnu_indirect_function` in ELF reader/writer/target asm parser. This RFC is looking for thoughts and suggestions about representation of ifunc in LLVM IR.

If changing nothing else I would probably go with another list since that is what is done for functions/variables/aliases. Having said that, more than once I wished we had an easy way to iterate all GlobalValues or all GrobalObjects. Any thoughts on the tradeoff having a single list with pointer to the start of each sub list? Something like Func1 <-> Func2 <-> Var1 <-> Var2

Are you going to have to teach LLVM how to look through ifuncs, or is it OK if they are totally opaque? For example, with __attribute__((target)), you might have one target-specialized function call another. Is it important that we be able to optimize away the dynamic dispatch there or not? Either way, I think a new IR construct is the way to go. On Fri, Dec 18, 2015 at 11:44 AM, Rafael

I would like to support __attribute__((target)) later so ifunc won't be opaque for compiler generated dispatchers. Thank you all for the feedback! On Sat, Dec 19, 2015 at 8:49 AM, Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think 2 is the only reasonable answer. And to answer Reid's comment: > yes, it might be nice if we could look through it for

Bringing the discussion to llvmdev. For the purposed of this discussion, object files can be thought as having just a few thing we care about: data, labels and relocations. Data is what at llvm ir would be just the contents of variables or functions. Relocations are utilities to compute the data at link time when it is not possible to do so earlier. For example, to compute a pcrel relocation we

> I agree that this accurately summarizes both (1) what’s expressible in > current object file formats and (2) what we’re likely to want to need from > global aliases. > >> The tool we have in llvm for creating these extra labels is the GlobalAlias. >> >> One way of representing the above uses is to be explicit: a label is >> created with a specific value or at

Itay, I tested on C6x in May with build 11343 and 11398, and it worked fine. I just ran the same test with build 11768, and there was no cancellation, just as you saw. I will try to track this down in the next day or two. In the meantime, I suggest that you try testing with 11398. - Jim ----- Original Message ----- From: Itay Chamiel To: speex-dev@xiph.org Sent: Monday, August 14,

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment. https://reviews.llvm.org/D26344 The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated