This is an archive of the discontinued LLVM Phabricator instance.

Set unroll remainder to epilog if profitable
ClosedPublic

Authored by evstupac on Nov 22 2016, 3:16 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

evstupac updated this revision to Diff 78953.Nov 22 2016, 3:16 PM
evstupac retitled this revision from to Set unroll remainder to epilog if profitable.
evstupac updated this object.
evstupac added reviewers: mzolotukhin, sanjoy.
evstupac set the repository for this revision to rL LLVM.
evstupac added subscribers: llvm-commits, mzolotukhin, sanjoy and 2 others.
mzolotukhin edited edge metadata.Dec 14 2016, 4:23 PM

Hi Evgeny,

Please find some comments inline.

Thanks

lib/Transforms/Utils/LoopUnroll.cpp
207 ↗(On Diff #78953)
  1. Latchis not used anywhere.
  2. && should be used instead of ||.
212–213 ↗(On Diff #78953)

This shouldn't be possible - I think we can assert this (if getIncomingValueForBlock doesn't assert it already).

215–216 ↗(On Diff #78953)

This also should not be possible, so we can replace it with assert.

221–225 ↗(On Diff #78953)

Where is this come from? Can you please elaborate what we're doing here?

360 ↗(On Diff #78953)

s/Epiplog/Epilog/

test/Transforms/LoopUnroll/unroll-pragmas.ll
181–184 ↗(On Diff #78953)

Can we also have a separate test for the new functionality?

evstupac updated this revision to Diff 83398.Jan 6 2017, 12:02 PM
evstupac updated this object.
evstupac edited edge metadata.

Removed modulo of unroll count check.
Simplified and updated according to inline comments.

PING.
Are there any major concerns regarding epilogue, besides this: https://bugs.llvm.org//show_bug.cgi?id=30939?
It looks like we are accepting epilogue for vectorization for some reason and can not accept it for unroll.

hfinkel accepted this revision.Feb 14 2017, 10:41 AM

PING.
Are there any major concerns regarding epilogue, besides this: https://bugs.llvm.org//show_bug.cgi?id=30939?
It looks like we are accepting epilogue for vectorization for some reason and can not accept it for unroll.

I think that we should move forward with this. PR30939, as explained in the bug report, does not seem like something we can reasonably work around - it seems like a prototypical microarchitectural sensitivity - dealing with branch predictors on unpredictable branches is always hard.

lib/Transforms/Utils/LoopUnroll.cpp
357 ↗(On Diff #83398)

No space before (L).

This revision is now accepted and ready to land.Feb 14 2017, 10:41 AM
mzolotukhin added inline comments.Feb 14 2017, 11:36 AM
test/Transforms/LoopUnroll/epilog_const_phi.ll
4 ↗(On Diff #83398)

s/inscombine/instcombine/
s/completle/completely/

I'd rather not rely on other passes (instcombine) to check loop-unroll. Can we check the CFG instead? That'll make the test smaller (since it'll be enough to have a minimal loop) and more robust to unrelated changes (say, instcombine for some reason stopped to simplify XOR through phis). It would be also nice to have a test, in which we don't use epilog (i.e. arguments of phis are not constant), to check that we're not doing it everywhere.

evstupac added inline comments.Feb 14 2017, 12:18 PM
test/Transforms/LoopUnroll/epilog_const_phi.ll
4 ↗(On Diff #83398)

I'd rather not rely on other passes (instcombine) to check loop-unroll. Can we check the CFG instead? That'll make the test smaller (since it'll be enough to have a minimal loop) and more robust to unrelated changes (say, instcombine for some reason stopped to simplify XOR through phis).

I agree, that right now it is more than unroll test. We can switch to CFG, but I'd like to leave XOR or smth else that shows clear profitability (when other optimizations are applied) instead of minimizing the loop.

It would be also nice to have a test, in which we don't use epilog (i.e. arguments of phis are not constant), to check that we're not doing it everywhere.

Good point. I'll add such.

mzolotukhin added inline comments.Feb 14 2017, 4:39 PM
test/Transforms/LoopUnroll/epilog_const_phi.ll
4 ↗(On Diff #83398)

I agree, that right now it is more than unroll test. We can switch to CFG, but I'd like to leave XOR or smth else that shows clear profitability (when other optimizations are applied) instead of minimizing the loop.

The goal of the tests is to test stuff, not to show profitability:) I'd rather mention the profitability in comments (which I think you already did). I think the smaller (~more decoupled) test the better.

I'll add such.

Thanks. Feel free to commit after it, no need to repost the updated patch.

This revision was automatically updated to reflect the committed changes.

I'll add such.

I think you forgot to commit the test. Did you rename the old test and forget to add it before committing?

Michael

I think you forgot to commit the test. Did you rename the old test and forget to add it before committing?

Yes. It looks like I forgot to add a new test. I'll add it today.

Thanks for catching this,
Evgeny