search for: antidepend

...) <<<<<<<<<<<<<<<<<< This is what I am missing. See below. return; // Add output dependence to the next nearest def of this vreg. // // Unless this definition is dead, the output dependence should be // transitively redundant with antidependencies from this definition's // uses. We're conservative for now until we have a way to guarantee the uses // are not eliminated sometime during scheduling. The output dependence edge // is also useful if output latency exceeds def-use latency. VReg2SUnitMap::iterator DefI = VRegDef...

...) and depend(S1,L1) would return a dependence), even though only one of the two dependences is valid when the chronological order of the instructions is considered. To illustrate consider this example: for(int i = 0; i < n; i++) { S0: A[i] = …; S1: … = A[i+1]; } In the example, there is an antidependence between S1 and S0 with distance 1. However, when querying DependenceInfo it also returns a flow dependence from S0 to S1. Is this the expected behavior of DependenceInfo or Is it a known problem? If it is the expected behavior, is there a way to check if the dependence you are getting back is a...

..._end()) > return; > > we do not ever get to this point: > > VRegDefs.insert(VReg2SUnit(Reg, SU)); > > But later, when checking for anti dependency for another MI here: > > void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { > ... > // Add antidependence to the following def of the vreg it uses. > VReg2SUnitMap::iterator DefI = VRegDefs.find(Reg); > if (DefI != VRegDefs.end() && DefI->SU != SU) > DefI->SU->addPred(SDep(SU, SDep::Anti, 0, Reg)); > > We will never find that def in VRegDefs.find(Reg) even thou...

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

> The lea->cmp problem is fixed by switching to the MI scheduler. Please run with -mllvm -misched-bench to confirm. I get the same output in the testcase in pr13320. The leaq is in between the cmp and the jmp, preventing macro-fusion. Cheers, Rafael

...ast one. if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) return; we do not ever get to this point: VRegDefs.insert(VReg2SUnit(Reg, SU)); But later, when checking for anti dependency for another MI here: void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { ... // Add antidependence to the following def of the vreg it uses. VReg2SUnitMap::iterator DefI = VRegDefs.find(Reg); if (DefI != VRegDefs.end() && DefI->SU != SU) DefI->SU->addPred(SDep(SU, SDep::Anti, 0, Reg)); We will never find that def in VRegDefs.find(Reg) even though it exists. I know thi...

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote: > ********** EXPANDING POST-RA PSEUDO INSTRS ********** > ********** Function: main > real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, > %D7<imp-def> > replaced by: %R15<def> = TFR %R4, %D7<imp-def> > > The R4 is a subreg of D2 double

On Nov 5, 2007, at 2:55 AM, Pekka Jääskeläinen wrote: > Hello LLVM people, > > Our customizable TTA target [1] is capable of having plenty of > registers > and register file ports to improve instruction level parallelism and > reduce spills. It's totally up to the designer of the particular TTA > processor how much the processor has registers and register file >

Hello everyone, I am running into an obscure issue with ExpandPostRA. Does anyone recognizes the following: The pass replaces a real copy with a "transfer" instruction: ********** EXPANDING POST-RA PSEUDO INSTRS ********** ********** Function: main real copy: %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>, %D7<imp-def> replaced by:

Hello LLVM people, Our customizable TTA target [1] is capable of having plenty of registers and register file ports to improve instruction level parallelism and reduce spills. It's totally up to the designer of the particular TTA processor how much the processor has registers and register file resources along with other TTA components. We have ported LLVM 2.1 to produce an intermediate TTA