[PATCH] D28915: [ExecutionDepsFix] Optimize instruction insertion
Keno Fischer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 17 14:32:00 PST 2017
loladiro added a comment.
I'll split up this review further and let's go from there.
================
Comment at: lib/CodeGen/ExecutionDepsFix.cpp:499
/// is truly dependent on, or use a register with clearance higher than Pref.
void ExeDepsFix::pickBestRegisterForUndef(MachineInstr *MI, unsigned OpIdx,
+ unsigned Pref, bool &TrueDependency) {
----------------
myatsina wrote:
> Why not make it return true/false (true dependency) instead of void?
>
That seems fine. I think I originally had it return a value, which is why I went this way, but since that's no longer the case, I'll update accordingly.
================
Comment at: lib/CodeGen/ExecutionDepsFix.cpp:628
+ // issues, reset the counter.
+ LiveRegs[rx].Def = -(1 << 20);
+ }
----------------
myatsina wrote:
> This feature should be heavily tested.
> This is the "xor fusion" logic, right?
>
> We're adding xors for dependency break in a late stage of the program, after clearance calculation of everyone was already done, including loops (i.e. you're previous patch that changes the calculation algorithm that you've comitted).
> Now you are changing the clearance for the xor's we've added, if I understand this correctly.
> So somehow you need to update your old clearance calculation, no?
> Or is this code aimed to only catch "xor"s that were in the original code.
>
> I would like to see a lot of tests for these feature (without the affect of the other features):
> How does it affect simple one BB code?
> What is the affect on simple loops with one xor to this register and no dependency?
> What is the affect on complex loops that no xors and assigns to the same register:
>
> loop:
>
> cvt
> xor xmm0
> cvt
> xmm0 =
> cvt
> cvt
> xor xmm0
> cvt
> xmm0 =
This is just for xors that were in the original code. xor fusion is no longer there, because it got subsumed by the register re-picking.
https://reviews.llvm.org/D28915
More information about the llvm-commits
mailing list