search for: visitload

...ding loads and then chains the volatile load onto them meaning that the volatile load must be scheduled after those loads. While this behaviour isn't wrong, it seems to reduce the scope for efficient instruction selection. Is there any reason not to modify the behaviour of SelectionDAGBuilder::visitLoad() so that volatile loads don't cause SelectionDAGBuilder::getRoot() to be called. Instead, they can be chained together with the head of the chain being stored in PendingLoads. Then when something else calls SelectionDAGBuilder::getRoot(), the chain of volatile loads is TokenFactored together w...

...volatile load onto them meaning that the volatile load > must be scheduled after those loads. While this behaviour isn't > wrong, it seems to reduce the scope for efficient instruction > selection. > > Is there any reason not to modify the behaviour of > SelectionDAGBuilder::visitLoad() so that volatile loads don't cause > SelectionDAGBuilder::getRoot() to be called. Instead, they can be > chained together with the head of the chain being stored in > PendingLoads. Then when something else calls > SelectionDAGBuilder::getRoot(), the chain of volatile loads is >...

...] Forcing the Interpreter segfaults I have build LLVM in debug mode. Here are the informations of the segfault : memcpy() at 0x7ffff6f6581e LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 0xb3c3f9 llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa16...

Is this piece of code in DAGCombiner::visitLOAD removing a dead node? 06155 if (N->use_empty()) { 06156 removeFromWorkList(N); 06157 DAG.DeleteNode(N); 06158 } If it is, is there a reason it doesn't push its operands to the work list as done in line 974-975? 00970 // If N has no uses, it is dead....

...re the informations of the > > segfault : memcpy() at 0x7ffff6f6581e > > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 > > 0xb3c3f9 > > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > >...

...meaning that the volatile load >> must be scheduled after those loads. While this behaviour isn't >> wrong, it seems to reduce the scope for efficient instruction >> selection. >> >> Is there any reason not to modify the behaviour of >> SelectionDAGBuilder::visitLoad() so that volatile loads don't cause >> SelectionDAGBuilder::getRoot() to be called. Instead, they can be >> chained together with the head of the chain being stored in >> PendingLoads. Then when something else calls >> SelectionDAGBuilder::getRoot(), the chain of volati...

Hi Akira, > Is this piece of code in DAGCombiner::visitLOAD removing a dead node? > > 06155 if (N->use_empty()) { > 06156 removeFromWorkList(N); > 06157 DAG.DeleteNode(N); > 06158 } yes. > If it is, is there a reason it doesn't push its operands to the work > list as done in line 974-975? &gt...

...=0x641bb08, N=0x6212a40) at /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703 #4 0x00a057c8 in CombineToPreIndexedLoadStore (this=0x7ee90f84, N=0x6238040) at /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5707 #5 0x00a07544 in visitLOAD (this=0x7ee90f84, N=0x6238040) at /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6011 #6 0x009e307c in visit (this=0x7ee90f84, N=0x6238040) at /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1099 #7 0x009e3148 in combine (this=0x7ee...

...le load >>> must be scheduled after those loads. While this behaviour isn't >>> wrong, it seems to reduce the scope for efficient instruction >>> selection. >>> >>> Is there any reason not to modify the behaviour of >>> SelectionDAGBuilder::visitLoad() so that volatile loads don't cause >>> SelectionDAGBuilder::getRoot() to be called. Instead, they can be >>> chained together with the head of the chain being stored in >>> PendingLoads. Then when something else calls >>> SelectionDAGBuilder::getRoot(), the...

...LLVM, I looked into the interpreter, where I found the target information is defined in TargetData class, and aggregate types (like struct and array) compute the correct padding and alignment from TargetData first before memory access. But I still run into one question, according to the code, the visitLoad/visitStore functions used by the interpreter does not allow accessing aggregate types, only simple types are legal. On the other hand, the GenericValue used by interpreter to store values in memory only considers simple types (int, float, typ*) too, and each 'getOperandValue' also takes ag...

...    at > /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703 > #4  0x00a057c8 in CombineToPreIndexedLoadStore (this=0x7ee90f84, > N=0x6238040) >     at > /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5707 > #5  0x00a07544 in visitLOAD (this=0x7ee90f84, N=0x6238040) >     at > /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6011 > #6  0x009e307c in visit (this=0x7ee90f84, N=0x6238040) >     at > /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1099 > #7  0x009e3...

Hi Jianzhou, > I misunderstood C99 ISO, such behaviors are defined not when types > have the same sizes, but when they are same (compatible) types with > signed or qualified extension (this is much stronger than being of > same sizes), or reading char by char: > > 7 An object shall have its stored value accessed only by an lvalue > expression that has one of > the

...as if the loads completed in order.) This means that we need to insert a synchronisation/serialisation instruction before both volatile and atomic loads. What would be the best way of doing that? Following the example of atomic fences, I wondered about adding a new ISD opcode and inserting it in visitLoad() and co in SelectionDAGBuilder. Would that be OK? Or is there a better way? Thanks, Richard

I have a platform that I am targeting that has 64-bit general purpose registers but uses 32-bit pointers (ie, sizeof(void*) == 4) but unfortunately it also requires that the top 32-bits of the pointer value be clear. This sometimes becomes a problem with certain pointer calculations such as using a 32-bit negative value for indexing into an array can cause the upper bits to be set, generating

...eTo(SDOperand Src, const Value *SrcV, + SDOperand Ptr, const Value *PtrV, + int Offset, bool isVolatile); + SDOperand getIntPtrConstant(uint64_t Val) { return DAG.getConstant(Val, TLI.getPointerTy()); } @@ -1814,28 +1962,28 @@ void SelectionDAGLowering::visitLoad(LoadInst &I) { SDOperand Ptr = getValue(I.getOperand(0)); + setValue(&I, getLoadFrom(I.getType(), Ptr, I.getOperand(0), + 0, I.isVolatile())); +} + +SDOperand SelectionDAGLowering::getLoadFrom(const Type *Ty, + SDOpe...

...t;CAB297QxcCQdpqMf7x89aAVyTiP0fDaqUxr_kjpRSX6BHAT=M7A at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Aug 26, 2011 at 9:52 AM, Duncan Sands <baldrick at free.fr> wrote: > > Hi Akira, > > > >> Is this piece of code in DAGCombiner::visitLOAD removing a dead node? > >> > >> 06155 ? ? ? ? if (N->use_empty()) { > >> 06156 ? ? ? ? ? removeFromWorkList(N); > >> 06157 ? ? ? ? ? DAG.DeleteNode(N); > >> 06158 ? ? ? ? } > > > > yes. > > > >> If it is, is there a reason i...