[llvm-dev] Adding LoopNest case to getIRName

[Arthur Eubanks via llvm-dev]

We should be consistent about whether we're passing the Loop or the
LoopNest to PassInstrumentation when we're running LoopNest passes.
Currently this is inconsistent in LoopPassManager.cpp. runSinglePass()
passes the LoopNest for a LoopNest pass,
but FunctionToLoopPassAdaptor::run() passes the Loop for a LoopNest pass.
So yes I think we should make runSinglePass() pass the Loop. The
alternative is to consistently pass the LoopNest, but then we end up having
to add more cases in the various StandardInstrumentations.

On Wed, May 12, 2021 at 6:20 PM raghesh <raghesh.a at gmail.com> wrote:

> Hi Arthur,
>
> Thanks for that update. Do you mean to say that runSinglePass is a (one of
> the) common place(s) where we can pass the Loop to PassInstrumentation even
> in LoopNest Mode? That would be ideal rather than updating
> PassInstrumentation as I could see other places also (similar to the
> following) where we should do the same.
>
> --- a/llvm/lib/Passes/StandardInstrumentations.cpp
> +++ b/llvm/lib/Passes/StandardInstrumentations.cpp
> @@ -861,6 +861,13 @@ bool OptNoneInstrumentation::shouldRun(StringRef
> PassID, Any IR) {
>    } else if (any_isa<const Loop *>(IR)) {
>      F = any_cast<const Loop *>(IR)->getHeader()->getParent();
>    }
> +  else  if (any_isa<const LoopNest *>(IR)) {
> +    const Loop *L = &any_cast<const LoopNest *>(IR)->getOutermostLoop();
> +    F = L->getHeader()->getParent();
> +  }
> +
>    bool ShouldRun = !(F && F->hasOptNone());
>    if (!ShouldRun && DebugLogging) {
>      errs() << "Skipping pass " << PassID << " on " << F->getName()
>
> Regards,
> ------------------------------
> Raghesh Aloor
> AMD India Pvt. Ltd.
> Bengaluru.
> ------------------------------
>
>
> On Wed, May 12, 2021 at 10:07 PM Arthur Eubanks <aeubanks at google.com>
> wrote:
>
>> Looks like even in LoopNest mode, FunctionToLoopPassAdaptor passes a Loop
>> to PassInstrumentation. But LoopPassManager::runSinglePass either passes a
>> Loop or LoopNest. Seems like that should be fixed to always pass the Loop
>> to PassInstrumentation.
>>
>> On Tue, May 11, 2021 at 11:26 PM raghesh via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi All
>>>
>>> While working on a LoopNest pass, I hit 'unreachable code' in the
>>> getIRName, which is invoked as part of debugging options (like
>>> -debug-pass-manager). It is figured out that within getIRName, LoopNest is
>>> not handled. I could fix it with the following patch.
>>>
>>> diff --git a/llvm/lib/Passes/StandardInstrumentations.cpp
>>> b/llvm/lib/Passes/StandardInstrumentations.cpp
>>> index e64df0b1147f..65e0e7d4cf27 100644
>>> --- a/llvm/lib/Passes/StandardInstrumentations.cpp
>>> +++ b/llvm/lib/Passes/StandardInstrumentations.cpp
>>> @@ -20,6 +20,7 @@
>>>  #include "llvm/Analysis/LazyCallGraph.h"
>>>  #include "llvm/Analysis/LoopInfo.h"
>>>  #include "llvm/IR/Function.h"
>>> +#include "llvm/Analysis/LoopNestAnalysis.h"
>>>  #include "llvm/IR/Module.h"
>>>  #include "llvm/IR/PassInstrumentation.h"
>>>  #include "llvm/IR/PassManager.h"
>>> @@ -285,6 +286,17 @@ std::string getIRName(Any IR) {
>>>      return OS.str();
>>>    }
>>>
>>> +  if (any_isa<const LoopNest *>(IR)) {
>>> +    const Loop *L = &any_cast<const LoopNest *>(IR)->getOutermostLoop();
>>> +    std::string S;
>>> +    raw_string_ostream OS(S);
>>> +    assert(L && "Loop should be valid for printing");
>>> +    L->print(OS, /*Verbose*/ false, /*PrintNested*/ false);
>>> +    return OS.str();
>>> +  }
>>> +
>>>    llvm_unreachable("Unknown wrapped IR type");
>>>  }
>>>
>>> Just wanted to make sure that this is the right fix and if it is so we
>>> can upstream this change.
>>>
>>> Regards,
>>> ------------------------------
>>> Raghesh Aloor
>>> AMD India Pvt. Ltd.
>>> Bengaluru.
>>> ------------------------------
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210512/a33540b9/attachment.html>