llvm dev - Oct 2016 - LCSSA verification for the top-level loops

> On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com>
wrote:
>> 
>> Hi Michael,
> Hi Igor,
Hi Michael,
> 
>> 
>> +CC llvm-dev
>> 
>> My guess is that it would be rather error prone to pinpoint exact
places where we start populating new LPPassManager since it’s created lazily via
LoopPass::assignPassManager. So we are risking to miss adding verifiers in some
of the LPPassManager’s.
> That’s true, I didn’t particularly like that either, but suggested as a
potential workaround.
>> 
>> One similar idea is to introduce LCSSAVerifier function pass and make
LCSSA pass to be dependant on it. That will allow me to check
‘getAnalysisIfAvaliable<LCSSAVerifier>’  inside of the LPPassManager and
explicitly call LCSSA verification when it’s present. This feels a quite hacky,
but in theory should work.
> We’ll always have to hack around something to pass a loop/list of loops to
verify to the function pass. Instead, I think it would be easier to create a
loop pass for LCSSAVerification and make all loop passes preserve it.
> 
> This way, when LPM would be verifying preserved analysis, it’ll run the
LCSSA verification for the current loop as well (verifyAnalysis from the new
pass). We can make it depend on the existing LCSSA pass, so that requiring this
one would result in building LCSSA if it’s not built yet. The verification
itself will be moved from the existing LCSSA pass’s verifyAnalysis to the new
pass’s verifyAnalysis (or we can keep verification in the original LCSSA pass as
well, but put it under a flag). Does it make sense?
Seems like verifyAnalysis for LoopPass doesn’t receive any information about
current loop, which leaves us with the same problem of verifying all loops on
each iteration. I guess we can introduce new verifyLoopAnalysis(Loop *L) method
and call it for all loop passes. It will also require separate
verifyPreservedLoopAnalysis(Loop *L). This seems like a cleanest solution. What
do you think?

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.
> 
> Thanks,
> Michael
> 
>> 
>> — Igor
>> 
>> On 14 Oct 2016, at 01:57, Mikhail Zolotukhin <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> 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.
>>>> 
>>> 
>>> 
>> 
>

Hi Igor,
> On Oct 17, 2016, at 10:39 AM, Igor Laevsky <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,
> 
>> 
>>> 
>>> +CC llvm-dev
>>> 
>>> My guess is that it would be rather error prone to pinpoint exact
places where we start populating new LPPassManager since it’s created lazily via
LoopPass::assignPassManager. So we are risking to miss adding verifiers in some
of the LPPassManager’s.
>> That’s true, I didn’t particularly like that either, but suggested as a
potential workaround.
>>> 
>>> One similar idea is to introduce LCSSAVerifier function pass and
make LCSSA pass to be dependant on it. That will allow me to check
‘getAnalysisIfAvaliable<LCSSAVerifier>’  inside of the LPPassManager and
explicitly call LCSSA verification when it’s present. This feels a quite hacky,
but in theory should work.
>> We’ll always have to hack around something to pass a loop/list of loops
to verify to the function pass. Instead, I think it would be easier to create a
loop pass for LCSSAVerification and make all loop passes preserve it.
>> 
>> This way, when LPM would be verifying preserved analysis, it’ll run the
LCSSA verification for the current loop as well (verifyAnalysis from the new
pass). We can make it depend on the existing LCSSA pass, so that requiring this
one would result in building LCSSA if it’s not built yet. The verification
itself will be moved from the existing LCSSA pass’s verifyAnalysis to the new
pass’s verifyAnalysis (or we can keep verification in the original LCSSA pass as
well, but put it under a flag). Does it make sense?
> 
> Seems like verifyAnalysis for LoopPass doesn’t receive any information
about current loop, which leaves us with the same problem of verifying all loops
on each iteration.
Indeed, I see the issue now.
> I guess we can introduce new verifyLoopAnalysis(Loop *L) method and call it
for all loop passes. It will also require separate
verifyPreservedLoopAnalysis(Loop *L). This seems like a cleanest solution. What
do you think?
The thing is that we seemingly haven’t had loop analyses so far, and probably
never will have them, as analyses usually work in at least a function scope.
While adding verifyPreservedLoopAnalysis and verifyLoopAnalysis seem kind of ok
to me, I think in the end it will only be used for verification of LCSSA and
LoopSimplify, which I don’t really like.
> 
> 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?

- Michael
> 
>> 
>> Thanks,
>> Michael
>> 
>>> 
>>> — Igor
>>> 
>>> On 14 Oct 2016, at 01:57, Mikhail Zolotukhin <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> 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/20161018/38f37d8a/attachment-0001.html>

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>