[PATCH] D137103: [LegacyPM] Port example pass SimplifyCFG to new PM

Sebastian Peryt via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 31 12:48:23 PDT 2022


speryt added a comment.

This is currently WIP patch, because I have some issues in understanding how exactly the porting should happen. I've been following @aeubanks recommendation from discourse <https://discourse.llvm.org/t/deprecation-of-enable-new-pm-option/65168/20?u=speryt>, but two main things that I found unclear so far are:

1. Should I retain legacy code, or can I safely drop it? In `Bye` pass I can see that legacy pass is still present, which for me makes little sense to copy for this pass. Especially because goal of this effort is to drop flag enabling run on legacy PM.



1. Looking for example at `llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp` it seems that different approach has been used to add support for new PM, which is closer to what documentation <https://llvm.org/docs/NewPassManager.html> is showing, rather what is presented in `Bye` pass. Mainly in the are of registration of new pass as well as pass options, which are using special processing function as I understand. Which way is "the proper one"?



================
Comment at: llvm/examples/IRTransforms/SimplifyCFG.h:19
 
 FunctionPass *createSimplifyCFGPass();
 
----------------
I couldn't find call to `createSimplifyCFGPass` anywhere. In other places (e.g. `llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp`)  similar function is actually used

```
// Public interface to the CFGSimplification pass
FunctionPass *
llvm::createCFGSimplificationPass(SimplifyCFGOptions Options,
                                  std::function<bool(const Function &)> Ftor) {
  return new CFGSimplifyPass(Options, std::move(Ftor));
}
```

Do we really need this function here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137103/new/

https://reviews.llvm.org/D137103



More information about the llvm-commits mailing list