similar to: [lld] avoid emitting PLT entries for ifuncs

In the context of support not only IFunc but DTrace, what kind of features do you want to add to lld, if you have a chance to implement it in the linker instead of a post-processing tool? I wonder if we can solve both of your problems. On Thu, Aug 23, 2018 at 1:33 AM Mark Johnston <markj at freebsd.org> wrote: > On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote: > > On 22

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

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

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.

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

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

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

Hi, I work with bio-conductor, but this is probably a basic R question. I want to emulate the GOBPOFFSPRING$"GO:0008150" command: > allBP <- GOBPOFFSPRING$"GO:0008150" > class(allBP) [1] "character" > length(allBP) [1] 16066 > I want to create a function so that I can execute the command by passing as a parameter the portion in quotes in the above

I was working on https://reviews.llvm.org/D81911 to try and fix https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review process we happened upon a design limitation or perhaps a potential mis-modelling of GlobalIFunc in the IR object hierarchy, which leads to some problems in LTO flows. To summarize, as it currently stands (and in the hopes of faithfully representing the conclusions of

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

Friends, I'm trying to pass an equation as an argument to a function. The idea is as follows. Let us say i write an independent function Ideal Situation: ifunc <- function(x) { return((x*x)-2) } mainfunc <- function(a,b) { evala <- ifunc(a) evalb <- ifunc(b) if (evala>evalb){return(evala)} else return(evalb) } Now I want to try and write this entire program in a single

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 22 August 2018 at 04:27, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, if you pass the -emit-relocs option to the linker, lld keeps all > relocations that have already been resolved in an output executable. By > analyzing a relocation table in a resulting executable, you could find all > locations where the ifunc PLT is called. Then, you can

Hi, It looks like the the ELFPassFile doesnot get an ordinal value assigned, as its added in a pass. Is there a way to assign a file ordinal for the files added by Passes ? Till that time, I am going to XFAIL the ifunc test. More tests should fail, and am not sure why they are not failing. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted

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 runtime. I've not given it much thought but I may need a new callable entity here (this is for the gnu ifunc stuff). Don't even know if this fits into the discussion, but since we were talking about weird symbols... -eric On Fri, May 23, 2014 at 1:26

Hello Tim, Thank you for getting back to me. The language grammar as defined by the LLVM Language Reference Manual [1] does not include the details of the LLVM IR parser reference implementation. The following extract from "lib/AsmParser/LLParser.cpp" illustrates that unnamed globals are allowed [2]. > /// ParseUnnamedGlobal: > /// OptionalVisibility (ALIAS | IFUNC) ...

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, > > As part of PR27551 I want to add a string table to the bitcode format to > allow global value and comdat names to be shared with the proposed symbol > table (and, as side effects, allow comdat

In addition I think the LayoutPass std::stable_sort be replaced with std::sort as total ordering is guaranteed as each File would get an ordinal and each atom would get an ordinal too, after the below problem is fixed. Thanks Shankar Easwaran On 10/6/2013 10:54 PM, Shankar Easwaran wrote: > Hi, > > It looks like the the ELFPassFile doesnot get an ordinal value > assigned, as its

Ping ? Do you think that we need to have an API in LinkingContext to return the next ordinal available, so that files created by passes can be assigned ordinals ? Thanks Shankar Easwaran On 10/6/2013 11:07 PM, Shankar Easwaran wrote: > In addition I think the LayoutPass std::stable_sort be replaced with > std::sort as total ordering is guaranteed as each File would get an >