[PATCH] D28724: Use getLoopLatch in place of isLoopSimplifyForm
Matthias Braun via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 17 10:49:53 PST 2017
MatzeB added a comment.
In https://reviews.llvm.org/D28724#648407, @trentxintong wrote:
> In https://reviews.llvm.org/D28724#648400, @MatzeB wrote:
>
> > In https://reviews.llvm.org/D28724#648397, @MatzeB wrote:
> >
> > > Why was this implemented as a unittest? Wouldn't this work just as good by inserting some debug prints and then using lit+opt+FileCheck to test?
> >
> >
> > Admittedly the same is true for many of the other tests in unittests/Analysis. Most of the times I just don't see the benefits of using unittests over lit+FileCheck, they are usually a lot harder to understand and debug.
>
>
> One problem I can see with LIT test here is that getLoopID() is not a transformation by itself, it depends on other transformations to call/use it. Would not using a LIT test for that tranformation making the testing a little bit more fragile/unpredictable, i.e. what if the transformation later is changed not to call this API or call it in a different way. Testing this way is a bit more specific I feel.
You can just request a single analysis from opt without running any transformation. It should work similar to this `opt -mypass -debug-only=mypass input.ll` if you use DEBUG(dbgs() << ) statements, alternatively there is the -analyze flag to opt, which ends up calling MyAnalysisPass::print().
There are number of tests in test/Analysis that work this way.
Repository:
rL LLVM
https://reviews.llvm.org/D28724
More information about the llvm-commits
mailing list