search for: slottrack

...is consistent with the output of an AssemblyWriter. Obviously this is easy for named instructions: In this case the identification is the name itself, but I'd like to have the same thing for unnamed instructions. If I understand the code in AssemblyWriter.cpp correctly, AssemblyWriter uses SlotTracker to keep track of the numbers used for unnamed instructions. Unfortunately for me SlotTracker is missing from LLVM's public header files. Is there any other way to retrieve a slot number for an Instruction that is consistent with the numbers assigned by an existing AssemblyWriter instance....

On Friday 13 November 2009 15:17, you wrote: > > Are these known to be broken right now? I get failure when using either. > > > > $ llc -march=arm -print-machineinstrs hw.bc > > Seems due to David's patches. Ok, it's faulting in SlotTracker with what looks like a bad Function. One of the Argument values is corrupted. I'm not abdicating responsibility, but at the moment I don't see the connection to my patches. Anton, are you seeing something specific as to the cause? I will keep investigating....

Hi Juan: I haven't looked at SlotTracker, but have been using MemoryDependenceWrapperPass to do something similar. hth... don On Fri, Dec 23, 2016 at 5:55 AM, Juan Ceasar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Good Morning - Happy Holidays everyone! > > I had a question about the best way to do back tracin...

...i32, i32* %1, align 4 %3 = icmp sgt i32 %2, 10 I’m grabbing the predicate of “icmp”, which in this case is a simple test “>” of the input “%num" and the constant “10" and I want to trace back to “%num" via the slots/virtual registers %2 and %1. I believe I can do this via the SlotTracker (in AsmWriter.cpp) but I wonder if there’s a better, more direct way? Any suggestions? I’m basically trying to track predicate formation in the IR and hence the need… Thanks for any help!

...e: > On Friday 13 November 2009 15:17, you wrote: >>> Are these known to be broken right now? I get failure when using either. >>> >>> $ llc -march=arm -print-machineinstrs hw.bc >> >> Seems due to David's patches. > > Ok, it's faulting in SlotTracker with what looks like a bad Function. One of > the Argument values is corrupted. > > I'm not abdicating responsibility, but at the moment I don't see the > connection to my patches. Anton, are you seeing something specific > as to the cause? > > I will keep inves...

...properties of prmitive Classes: get Opcode of each instruction, get ValueID of a subclass of Value. For example, given an AllocationInst, it can return the allocation size, and other accessing methods for different kinds of Instructions. To generate names for unnamed values, the patch also makes SlotTracker visibly from ./lib/VMCore/AsmWriter.cpp to ./include/llm/Assembly/Writer.h. Such bindings are defined at ./binding/OCaml/llvm with other changes at ./lib/VMCore/Core.cpp ./include/llvm-c/Core.h 2) also more bindings to parse data layout. The existing methods in llvm::TargetData do...

You can get the name of a variable by using the method getName() of llvm::Value. However it returns a blank string if the variable is a numbered variable, such as %11. How can I make it return %11 in such case. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130222/d6d434e8/attachment.html>

...[.] llvm::TypeFinder::incorporateType(llvm::Type*) >> 7.54% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >> 2.26% opt opt [.] llvm::SlotTracker::processModule() >> >> It is surprise that all compile-time for TypeFinder is added into the compile-time for Polly-detect, but I cannot find the any call instructions to TypeFinder in Polly-detect. > >Yes, this does not seem very conclusive. We probably need a call graph >t...

...l>, %SP, %reg0, 4, 14, %reg0; mem:ST4[0 llc 0x008b3304 PrintStackTrace(void*) + 45 1 llc 0x008b390c SignalHandler(int) + 410 2 libSystem.B.dylib 0x93130b9b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1827468431 4 llc 0x0078d74b createSlotTracker(llvm::Value const*) + 114 5 llc 0x00790c21 WriteAsOperandInternal (llvm::raw_ostream&, llvm::Value const*, llvm::TypePrinting*, (anonymous namespace)::SlotTracker*) + 799 6 llc 0x00794089 llvm::WriteAsOperand (llvm::raw_ostream&, llvm::Value const*, boo...

...Type(llvm::Type*) >>> 7.54% opt opt [.] >>> llvm::TypeFinder::incorporateValue(llvm::Value const*) >>> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >>> 2.26% opt opt [.] >>> llvm::SlotTracker::processModule() >>> >>> It is surprise that all compile-time for TypeFinder is added into the >>> compile-time for Polly-detect, but I cannot find the any call instructions >>> to TypeFinder in Polly-detect. >> >>Yes, this does not seem very conclu...

...t;>>> 7.54% opt opt [.] >>>> llvm::TypeFinder::incorporateValue(llvm::Value const*) >>>> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >>>> 2.26% opt opt [.] >>>> llvm::SlotTracker::processModule() >>>> >>>> It is surprise that all compile-time for TypeFinder is added into the >>>> compile-time for Polly-detect, but I cannot find the any call instructions >>>> to TypeFinder in Polly-detect. >>> >>>Yes, this d...

...a const*>::ret_type llvm::cast<llvm::ValueAsMetadata, llvm::Metadata const>(llvm::Metadata const*) /llvm/include/llvm/Support/Casting.h:239:0 #10 0x00007f50bc679010 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::Me...

...[.] llvm::TypeFinder::incorporateType(llvm::Type*) >> 7.54% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >> 2.26% opt opt [.] llvm::SlotTracker::processModule() >> >> It is surprise that all compile-time for TypeFinder is added into the compile-time for Polly-detect, but I cannot find the any call instructions to TypeFinder in Polly-detect. > >Yes, this does not seem very conclusive. We probably need a call graph >t...

> Are these known to be broken right now? I get failure when using either. > > $ llc -march=arm -print-machineinstrs hw.bc Seems due to David's patches. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...te: > >>> Are these known to be broken right now? I get failure when using > >>> either. > >>> > >>> $ llc -march=arm -print-machineinstrs hw.bc > >> > >> Seems due to David's patches. > > > > Ok, it's faulting in SlotTracker with what looks like a bad Function. > > One of the Argument values is corrupted. > > > > I'm not abdicating responsibility, but at the moment I don't see the > > connection to my patches. Anton, are you seeing something specific > > as to the cause? > &...

hi Sean Silva: i really appriciate for your reply. but you konw that "dump()" instruction can print "%4" in the screen and each time print the same name "%4" not "%5" or "%6" for the same unnamed value. so there must be a way to determinate it. if "dump()" instruction can print it on the screen, can i find some way to store it in a char *

On Sun, Jul 14, 2013 at 10:17 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi Sebastian, > > Yes, you have pointed an important reason. If we comment this source code > you have listed, then the compile-time overhead for oggenc*8.ll can be > reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). > > I just sent another mail to explain why polly-detect pass leads to >

How can I get the name of the virtual Registers present on an instruction. eg. %add18 = add nsw i32 %mul17, %37 in this case I want to extract the name of the virutal registers as "add18", "mul17","37". This can easily be done in the case of store Instruction eg. store i32 %add20, i32* %t, align 4 in this case functions like

...[.] > llvm::TypeFinder::incorporateType(llvm::Type*) > 7.54% opt opt [.] > llvm::TypeFinder::incorporateValue(llvm::Value const*) > 2.66% opt libc-2.17.so [.] 0x0000000000138c02 > 2.26% opt opt [.] > llvm::SlotTracker::processModule() > > It is surprise that all compile-time for TypeFinder is added into the > compile-time for Polly-detect, but I cannot find the any call instructions > to TypeFinder in Polly-detect. > > Do you have further suggestion? > You can try to set a breakpoint with...

On 07/14/2013 08:05 AM, Star Tan wrote: > I have found that the extremely expensive compile-time overhead comes from the string buffer operation for "INVALID" MACRO in the polly-detect pass. > Attached is a hack patch file that simply remove the string buffer operation. This patch file can significantly reduce compile-time overhead when compiling big source code. For example, for