search for: pendingload

...+ SchedulerMemoryDisambiguationAA( + "sched-alias-analysis", cl::Hidden, + cl::desc("Include alias analysis in memory disambiguation for scheduling")); } // namespace namespace { @@ -364,10 +374,9 @@ std::map<const Value*, SDOperand> NodeMap; - /// PendingLoads - Loads are not emitted to the program immediately. We bunch - /// them up and then emit token factor nodes when possible. This allows us to - /// get simple disambiguation between loads without worrying about alias - /// analysis. + /// PendingLoads - Some loads and stores are not emitted t...

...Us, or the DAG will remain illegal. Here is my little example again, where SU(0) and SU(2) have a store - load memory dependence which must be modelled with an edge. SUnits: SU(0) Store to address A SU(1) Store to address B SU(2) Load from address A DAG building, bottom-up: SU(2) gets pushed onto PendingLoads. SU(1) becomes AliasChain. A MayAlias edge is added between SU(2) and SU(1). SU(0) becomes AliasChain. TII->areMemAccessesTriviallyDisjoint() says that SU(0) and SU(1) are disjoint, and gets no edge, and SU(1) is inserted into RejectMemNodes (SU(1) and SU(2) were not trivially disjoint). At th...

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the > SelectionDAGLowering::visitStore So, if I now detect in the getRoot that there are more than let's say 64 nodes in the PendingLoads queue, wha...

...) // Store a register in two parts SU(3): store dataReg0:hi, *addrReg0 SU(4): dataReg1:lo = load *addrReg1(2) // Load a register in two parts SU(5): dataReg1:hi = load *addrReg1 Since the addresses are loaded from memory, the underlying Objs become empty for all MIs. SU(4) and SU(5) get pushed to PendingLoads. SU(3) becomes AliasChain, and edges are added to SU(4) and SU(5). PendingLoads is cleared. SU(2) becomes AliasChain. This time TII->areMemAccessesTriviallyDisjoint() return true, since it can see that addrReg0 with and without offset are disjoint. This was not the case between SU(3) and SU(4),...

...ce 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 with the non-volatile loads. I've tried this out and it seems to do what I want but as I'm fairly inexperienced with LLVM, I'm not sure whether there's something el...

.... April 2008, 08:33:25 Uhr Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the > SelectionDAGLowering::visitStore So, if I now detect in the getRoot that there are more than let's say 64 nodes in the PendingLoads queue, wha...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

...ve you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB with tens of thousends of instructions, there is a TokenFactor node N that has ... 3200 operands! (These operands are PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the TokenFactor node by SelectionDAGLowering::getRoot called from the SelectionDAGLowering::visitStore). During the code selection phase, the SelectionDAG::ReplaceAllUsesWith is called many times and in many cases it tried...

...ion > 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 with the non-volatile loads. I've tried this > out and it seems to do what I want but as I'm fairly inexperienced > with LLVM, I'm not sure whether ther...

...> >> 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 with the non-volatile loads. I've tried this >> out and it seems to do what I want but as I'm fairly inexperienced >> with LLVM, I'm not s...

...s 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 with the non-volatile loads. I've tried this >>> out and it seems to do what I want but as I'm fairly inexperienced >>> with LLV...