search for: moduleslottracker

...WriteAsOperandInternal(llvm::raw_ostream&, llvm::Metadata const*, (anonymous namespace)::TypePrinting*, llvm::SlotTracker*, llvm::Module const*, bool) /llvm/lib/IR/AsmWriter.cpp:2045:0 #11 0x00007f50bc680e2c printMetadataImpl(llvm::raw_ostream&, llvm::Metadata const&, llvm::ModuleSlotTracker&, llvm::Module const*, bool) /llvm/lib/IR/AsmWriter.cpp:3504:0 #12 0x00007f50bc680fcc llvm::Metadata::printAsOperand(llvm::raw_ostream&, llvm::ModuleSlotTracker&, llvm::Module const*) const /llvm/lib/IR/AsmWriter.cpp:3520:0 #13 0x00007f50bd2ee8e2 llvm::MachineOperand:...

...your real application do not have this kind of bottle neck. this is a valid idea, thought the problem is: I output all things only "once" and I even output it like: 1) load module 2) go over functions 3) output all blocks with instructions in the current function That allows to e.g. use ModuleSlotTracker to compute the <label> comments of blocks fast, as each function is only visited once. Still, the performance drop to just print each instruction once is "large", without instruction printing my control flow graph construction works in ~1 second, with printing I aborted after some...

...lvm::Value::print to output the assembly strings for llvm::Instructions inside a rather large llvm::Module (linked module with lots of types/...). I started with plain ::print and switched over to http://llvm.org/docs/doxygen/html/classllvm_1_1Value.html#a04e6fc765eeb0c4c90ac5d55113db116 with a ModuleSlotTracker I pass in myself to avoid some complexity. Still now I have the issue that the TypeFinder::run and related that is done internally by each print still is 99% of my program runtime. (at least perf tells me that) Is there any clever workaround for this? I looked a bit through the sources but it se...

Hi all, When writing my custom passes, I often emit log messages to llvm::errs() like so: llvm::errs() << "Could not handle instruction: " << *Inst << std::endl; where Inst is a pointer to an Instruction. I've profiled my code and found that this way of printing an Instruction takes a very long time: indeed, it is the bottleneck of my pass. Of course, I could

Hi. I want to do a cutomized points-to analysis on IR. Suppose that we have: *%91 = bitcast i8* %90 to %struct.demux_packet*, !dbg !2688* I want to store sth similar to %91 -> target of %90, which records the target of pointer named %91. How can I access the names (Here, %90 and %91)? I know that I can put the whole line for an instruction into a string, using the following code: *string str;*

...I access the names (Here, %90 and %91)? > > Unfortunately it's not trivial. You can see the logic used in > AssemblyWriter::printInstruction (in lib/IR/AsmWriter.cpp). > > It boils down to using Instruction::getName if it exists, otherwise > there's a special class called ModuleSlotTracker (the "Machine" > instance in that function) that gives each unnamed value a number. > You'd have to create one of those yourself; I had a quick look at the > header and it actually seems pretty easy to use, which was a pleasant > surprise. > > Cheers. > > Tim....

Hi everybody, I want to read the name of the arguments of fucntion IR LLVM, I have the following function define: define void @vecadd(i32, float* nocapture readonly, float* nocapture readonly, float* nocapture) local_unnamed_addr #0 { As we see, the argument has no name, if we look at call function in main function we see the arguments name (a, b and c): call void @vecadd(i32 10, float*

Hi all, I have %5 = load i32, i32* %3, align 4 LoadInst and I would like to get reference to the destination ( in this case %5 ). How can I do that? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181212/1d0bd00c/attachment.html>

I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20%