similar to: [LLVMdev] Filename in dynamically loaded function pass

On 7 July 2011 02:27, Kodakara, Sreekumar V <sreekumar.v.kodakara at intel.com> wrote: > I would like to know if there is an API/method that I can use to get the > name of the file being processed in a dynamically loaded function pass. In > other words, if I invoke a pass as follows > > opt  -load pass.so -hello  src.bc –o src.hello.bc > > where pass.so is a

Hi All, I am using llvm-3.0 release version for compiling some files. I have a cpp file on which I did a few custom passes. After that I used llc to convert the *.bc file to *.s file at -O1 optimization level. llc took ~2630 seconds to perform this conversion. I timed llc and these are the top three passes that is taking most of the time. ---User Time--- --System Time-- --User+System--

I have developed a pass to instrument LLVM bit code files with calls to a custom instrumentation library. For one of the instrumentation calls, I need to pass the name of the temporary variable used in LLVM bit code. For example, if I see LLVM assembly code as shown below, %13 = icmp eq i64 %11, 0, !dbg !14 After the instrumentation pass, it needs to look like the following %13 = icmp eq i64

On 2/25/11 1:50 PM, Kodakara, Sreekumar V wrote: > I have developed a pass to instrument LLVM bit code files with calls to a custom instrumentation library. For one of the instrumentation calls, I need to pass the name of the temporary variable used in LLVM bit code. > > For example, if I see LLVM assembly code as shown below, > > %13 = icmp eq i64 %11, 0, !dbg !14 > > After

Hi All, I am creating an instrumentation pass using LLVM libraries. I am using clang++ (version 2.9) to compile cpp code into LLVM bit code. When I generate the llvm bit code using clang++ using -O3, I get many instances of instructions that look like the following. br i1 icmp ne (i8* bitcast (i32 (i32)* @pthread_cancel to i8*), i8* null), label %bb23, label %bb25 Here three LLVM instructions

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > Hi All, > > I have a question on ConstantExpressions and llvm intrinsic > memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C > programs that I am compiling using clang frontend, the call to memcpy > instrinsic looks like the following > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called.

I have a whole slew of questions about optimization passes. Answers to any or all would be extremely helpful: How important are doInitialization/doFinalization? I can't detect any difference if I use them or not. Why does the function pass manager have doInitialization/doFinalization, but the global pass manager doesn't? If I am applying the function passes to many functions, do I

On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > >> I'm wondering if the documentation for LoopPass >> (http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>

On 5/6/15 10:19 AM, Kuperstein, Michael M wrote: > > Hello Cristiano, > > I don’t think doFinalization() is really meant to be used this way. > My understanding is that doInitialization() and doFinalization() are designed specifically for modifying the LLVM IR (otherwise, why would a mutable reference to the Function be provided)? If that is not the case, then there is either a

Hi Chandler, On 17/12/12 13:47, Chandler Carruth wrote: > On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > > I'm wondering if the documentation for LoopPass >

Hello All, There is an issue in AddressSanitizer today because it depends on it's doFinalization method be called before the Printer method to output the final code (that is the printer runOnModule call). This assumption seems invalid as the doFinalization method should AFAIK only be used for clean up tasks independent of activities of other passes. When I try to call doFinalization inside

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

Hello Yiannis, I am not an expert on metadata or the CG information but one of the two has to happen: - Simply moving the deleter pass to a different spot - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order is the reverse of the doInitialization order) Option 1 is a smaller change, option 2 will make the code

I'm wondering if the documentation for LoopPass ( http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or incorrect (or if I'm just missing something.) The documentation states: "The doFinalization method ... is called when the pass framework has finished calling runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for every loop in the program being

Hi, I would like to run the -O1 pass sequence followed by -reg2mem from an out of tree project which uses llvm. I am using the following code snippet to do so but in some cases, my method is also vectorising the code, which doesn't happen when running the same sequence(-S -O1 -reg2mem) through opt. Can someone please help me find what I am missing? Thanks, Akash. *

Hi Stephen, On 13/12/12 18:58, Stephen McGruer wrote: > I'm wondering if the documentation for LoopPass > (http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has finished > calling runOnLoop

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if