similar to: Finding all pointers to functions

On 12/22/15 4:45 AM, Russell Wallace via llvm-dev wrote: > Oh, I just came across Function::hasAddressTaken. Maybe I can just use > that instead? You could conservatively assume that any function that has its address taken has a pointer to it that escapes into memory or external code. To make things a little more accurate, you could scan the uses of any function for which

> On 2015-Oct-12, at 10:41, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Vedant Kumar wrote: >>>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >>>> >>>> Could someone else chime in on what

Eric Christopher wrote: > How are you trying to call it? Do you have a DataLayout? In test/Analysis/ValueTracking/memory-dereferenceable.ll, just change byval to dereferenceable(8), and %dparam won't match (see lib/IR/Value.cpp:521 for the logic that is supposed to fire). How do I get it to pass? I tried introducing a target-triple and target-datalayout, but it didn't help.

David Majnemer wrote: > > > On Mon, Oct 12, 2015 at 11:00 AM, Duncan P. N. Exon Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 2015-Oct-12, at 10:41, Sanjoy Das > <sanjoy at playingwithpointers.com > <mailto:sanjoy at playingwithpointers.com>> wrote: > > >

Here is a WIP patch as promised: http://reviews.llvm.org/D13829 It uses a hungoff uselist to store optional data as needed. Some early objections from Duncan: - An extra one-time malloc() is required to set personality functions. - We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down. Is this overhead

>> That's a neat idea. To summarize: make Function have 3 optional operands. (For context -- Function currently has 1 optional operand, and my proposal is to move to 0.) >> >> Could someone else chime in on what they'd like to see? > > Sanjoy's idea makes sense to me, but only if we never need to add > prefix/prologue data after functions are created. Are

I've done some measurements on this. The test program I have just calls Function::Create(), F->setPersonalityFn(), and then F->eraseFromParent() in a loop 2^20 times. Results: pre-patch --- min: 1.10s max: 1.13s avg: 1.11s post-patch --- min: 1.26s max: 1.35s avg: 1.29s So we expect to lose 0.2 seconds per 1 million functions (with personality functions) in a

Function's have three kinds of optional data: prefix data, prologue data, and personalities. We don't have a consistent way of storing this data, IMO. This RFC discusses a new way of managing optional data that makes llvm::Function cleaner, more consistent, and a little smaller. What do we do currently? ======================== Prefix and prologue data are attached to Functions via

This code: int main(int argc, char **argv) { puts("abc"); return 0; } compiles to this: @"\01??_C at _03FIKCJHKP@abc?$AA@" = linkonce_odr unnamed_addr constant [4 x i8] c"abc\00", comdat, align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** nocapture readnone %argv) #0 { %1 = tail call i32 @puts(i8* getelementptr inbounds ([4 x i8], [4

Hi Sanjoy, > I don't know how prologue and prefix data is used -- is it correct to > say that you're basically trying to give `llvm::Function` s some > "optional" operands, and that you know during construction of an > `llvm::Function` how many optional operands the `llvm::Function` will > need[1]? Yep. Though not operands exactly, since they wouldn't be in

On 12/23/15 2:09 AM, Russell Wallace wrote: > On Tue, Dec 22, 2015 at 10:55 AM, John Criswell <jtcriswel at gmail.com > <mailto:jtcriswel at gmail.com>> wrote: > > You could conservatively assume that any function that has its > address taken has a pointer to it that escapes into memory or > external code. > > > Right, that's what I'm

On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com> wrote: > On 6/20/16 11:29 PM, Mehdi Amini wrote: > > > On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: > > Dear Community, > > To improve current interprocedural register

I have the following prototype for a function: void bkp_memory(char *, int); Inside my LLVM IR, I have a callsite looks like the following: tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind When I try to obtain its 1st argument and check whether it is a valid instruction, using: Instruction *Inst = dyn_cast<Instruction *>(I->getOperand(0)); it gives me a

> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: >> Dear Community, >> >> To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way:

Dear Community, To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way: if (F->hasLocalLinkage() && !F->hasAddressTaken()) { DEBUG(dbgs() << "Function has LocalLinkage \n"); F->setCallingConv(CallingConv::GHC); } but we think threre

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to

Rather than including llvm header files piecemeal on an ongoing basis, I'm looking for a way to include all such header files once and for all. To that end, I wrote a Python script to generate include directives for all .h files in llvm/include and its subdirectories. This almost works, but getting two error messages: In file included from src\main.cpp:1: In file included from

Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something

On 5/16/11 9:35 AM, Chuck Zhao wrote: > I have the following prototype for a function: > void bkp_memory(char *, int); > > Inside my LLVM IR, I have a callsite looks like the following: > tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind > > > When I try to obtain its 1st argument and check whether it is a valid > instruction, using: >

John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different