[llvm-dev] LCSSA verification for the top-level loops

Igor Laevsky via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 19 10:57:22 PDT 2016


Hi Igor,

On Oct 17, 2016, at 10:39 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote:

On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote:

Hi Michael,
Hi Igor,

Hi Michael,

Hi Michael,


What I was referring to is that we can write something like this inside LPPassManager iteration:
 if (getAnalaysisIfAvaliable<LCSSAVerifier>()) { CurrentLoop->verifyLCSSA(); )
This will have less impact but feels a bit wrong.
Originally I didn’t like this idea, but the more I think about it the more I like it. Currently all loop passes use (or should use) getLoopAnalysisUsage to record their pass requirements, so all of them should operate on the same set of analyses. What we can do is to add a function verifyLoopAnalyses to LPM and make it call verifiers for all these analyses.

So, instead of
if (getAnalaysisIfAvaliable<LCSSAVerifier>()) { CurrentLoop->verifyLCSSA(); )
we will have
  verifyLoopAnalyses(CurrentLoop);
which will do:
  CurrentLoop->verifyLCSSA();
  CurrentLoop->verifyLoopSimplify(); // For beginning we can skip everything except LCSSA
  CurrentLoop->verifySomethingElse()
  etc.

What do you think?

Unfortunately there are loop print passes (LoopPassPrinter and PrintLoopPassWrapper) which don’t require LCSSA. And I think it’s important to support ability to print loops without mandatory LCSSA verification. Probably loop printers can be converted to function passes, but in that case we will execute them only once per LPPassManager, which is also not an option. Now I’m not sure how to better bypass this issue. Do you have any ideas?


- Michael



Thanks,
Michael


— Igor

On 14 Oct 2016, at 01:57, Mikhail Zolotukhin <mzolotukhin at apple.com<mailto:mzolotukhin at apple.com>> wrote:

Hi Igor,

I like the second option more, and I think we can do something like this, or even more general. I'd suggest creating a new loop pass, called e.g. LoopVerification, and manually (at least for now) add it as a last pass to every instance of LPM. The pass will directly call isRecursivelyInLCSSA for the current loop, and later probably can also check other properties like LoopSimplify This way, the verification will be executed when all loop passes have finished working with a loop and before going to another loop. We can also schedule it in between some passes if we'd like to, and we can schedule it after all loop passes, placing it into a separate LPM instance. What do you think?

For now I don't have a good idea on how to utilize PassManager to schedule such verifiers automatically though:-(

- Michael

PS: Did you mean to send it to the list? Chandler might have good ideas here.


On Oct 13, 2016, at 8:30 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote:

Hi Michael,

In the https://reviews.llvm.org/D25364 we were discussing possibility of verifying LCSSA only for the top-level loops. I started implementing this but process appears to be a bit tricky. Problem is that I can’t find a way to check that LPPassManager contains LCSSA pass without introducing circular dependency between TransformUtils and Analysis libraries. I have couple of solutions in mind but wanted to ask your opinion on those, maybe we will be able to arrive at better decision.

1. I can introduce list of loops which LCSSAWrapperPass::verifyAnalysis needs to verify. It will be stored in the LoopInfo and populated in the LPPassManager main loop. After verification LCSSAWrapperPass will remove loop from this list.


2. There could be separate analysis “LCSSAVerification” on which LCSSA pass will depend. That way I will be able to recognise it inside LPPassManager and manually call verification of the current loop. Not sure how well our pass managers can handle such dependencies.

None of those seem particularly appealing to me. What do you think? Is there any better way?

Thanks,
Igor.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/8e50d27c/attachment.html>


More information about the llvm-dev mailing list