Displaying 10 results from an estimated 10 matches for "antidependence".
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...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 this...
2020 Apr 23
2
Incorrect behavior in the LLVM dependence analyzer
...) 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 cor...
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
..._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 i...
2012 Jun 13
4
[LLVMdev] Assert in live update from MI scheduler.
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;
2013 Oct 05
1
[LLVMdev] Codegen performance issue: LEA vs. INC.
> 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
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
...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 this ha...
2012 Jul 09
0
[LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO INSTRS
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
2007 Nov 05
0
[LLVMdev] allocating registers less "sparingly"
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
>
2012 Jul 08
2
[LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO INSTRS
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:
2007 Nov 05
6
[LLVMdev] allocating registers less "sparingly"
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