search for: writeasoperand

...t; The reason for the slow pretty printing of types is the same as > previously discussed in: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html Just removing those calls looks like a hack as it yields -analyse output without named regions. On the other side, having calls to WriteAsOperand in Region::getNameStr() is the cause of this slowdown. It helps us to provide a reasonable way to name regions that do have unnamed basic blocks. If we can find a better/faster way to name such regions we could remove the call to WriteAsOperand without regrets. We could e.g. just assign an incre...

Hi, in lib/Analysis/RegionPass.cpp there are 3 occurrences of: CurrentRegion->getNameStr() These are slowing down compile times with polly. I would suggest to either remove these calls, or only turn on when the programmer asks for -debug. The reason for the slow pretty printing of types is the same as previously discussed in: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html

...aph<MachineFunction *> F) { return "DFG for the function"; } static std::string getSimpleNodeLabel(Value *Node, const MCDFGraph<MachineFunction *> &F) { std::string Str; raw_string_ostream OS(Str); WriteAsOperand(OS, Node, false); return OS.str(); } static std::string getCompleteNodeLabel(Value *Node, const MCDFGraph<MachineFunction *> &F) { std::string Str; raw_string_ostream OS(Str); if (!Node->getName().empty()) {...

...mizer.cpp:16: In file included from /Developer/llvm/lib/Transforms/ThreadBufferOptimizer/ThreadBufferOptimizer.h:20: In file included from /Developer/llvm/include/llvm/Analysis/PostDominators.h:17: /Developer/llvm/include/llvm/Analysis/Dominators.h:158:5: error: use of undeclared identifier 'WriteAsOperand' WriteAsOperand(o, Node->getBlock(), false); ^ /Developer/llvm/include/llvm/Analysis/Dominators.h:170:41: note: in instantiation of function template specialization 'llvm::operator<<<llvm::CallGraphNode>' requested here o.indent(2*Lev) << "["...

...urn "DFG for the function"; > } > > static std::string getSimpleNodeLabel(Value *Node, > const MCDFGraph<MachineFunction > *> &F) { > std::string Str; > raw_string_ostream OS(Str); > > WriteAsOperand(OS, Node, false); > return OS.str(); > } > > static std::string getCompleteNodeLabel(Value *Node, > const > MCDFGraph<MachineFunction *> &F) { > std::string Str; > raw_string_ostream OS(Str); &gt...

...04 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*, bool, llvm::Module const*) + 126 7 llc 0x005dce23 llvm::operato...

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

...operand of the StoreInst is being reported as "void <badref>". > First, I don't really know what this means but I assume its just an > invalid references of some sort. Actually, that is the store instruction itself. The verifier was mistakenly passing the store into 'WriteAsOperand', which, since it returns void, isn't a valid reference. Now it should print the actual instruction itself. > The only thing I store into the array > is an "IntTy". I use a GEP instruction to index into the stack and then > generate the store instruction like this: >...

Hi , I am using LLVM for my Post Graduate course project on Optimization. I am trying to do some insrtumentation to the bytecode.I 've been going through your Instrumentation code for the past few days in /llvm/lib/Transforms/Instrumentation folder and finally found two ways of instrumentation : 1) injecting LLVM bytecode instructions 2) calling an external C function. I am trying both and

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

...`struct llvm::Module' /projects/compiler/llvm-gcc/gcc/llvm-internal.h:45: error: forward declaration of `struct llvm::Module' /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp: In function `void print_llvm(FILE*, void*)': /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:1036: error: `WriteAsOperand' was not declared in this scope /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp: In function `void print_llvm_type(FILE*, void*)': /projects/compiler/llvm-gcc/gcc/llvm-backend.cpp:1045: error: `WriteTypeSymbolic' was not declared in this scope make[2]: *** [llvm-backend.o] Error 1 ma...