[PATCH] D69930: [OpenMP] Introduce the OpenMPOpt transformation pass
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 8 10:08:15 PST 2019
jdoerfert marked 2 inline comments as done.
jdoerfert added inline comments.
================
Comment at: llvm/include/llvm/Transforms/IPO/OpenMPOpt.h:19
+/// OpenMP optimizations pass.
+struct OpenMPOptPass : public PassInfoMixin<OpenMPOptPass> {
+ PreservedAnalyses run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
----------------
ABataev wrote:
> Better to use `class`? Also, maybe worth it to mark it as `final`.
I can do that but I do not understand why this would be better (in a lot of situations, including this one).
After all, class will just cause an additional `public` and that is it (for all but MSVC and only if we declare this struct/class again which we never do). Similarly, I have never seen an attempt to inherit from a new-PM style pass and if so it is unclear why we should forbid it (with `final`).
================
Comment at: llvm/lib/Transforms/IPO/OpenMPOpt.cpp:145
+ if (CallInst *CI = getCallIfRegularCall(*U, &RFI)) {
+ CI->moveBefore(&*F.getEntryBlock().getFirstInsertionPt());
+ ReplVal = CI;
----------------
ABataev wrote:
> What if the function is already in the entry block?
Not a problem and not sufficient:
If we have the following entry and the first use we visit is (for some reason) `%gtid1` we need to move it because it would not dominate the use of `%gtid0`.
```
entry:
%gtid0 = call __kmpc_global_thread_num ...
... use(%gtid0)
%gtid1 = call __kmpc_global_thread_num ...
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69930/new/
https://reviews.llvm.org/D69930
More information about the llvm-commits
mailing list