[PATCH] D69930: [OpenMP] Introduce the OpenMPOpt transformation pass

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert marked 5 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:
> jdoerfert wrote:
> > ABataev wrote:
> > > jdoerfert wrote:
> > > > 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`).
> > > Up to you. But if you going to have `private` or `protected` members later, better to make `class` rather than `struct`.
> > > Up to you. But if you going to have private or protected members later, better to make class rather than struct.
> > 
> > Why? They are the same except the default visibility.
> Coding standard
The Coding standard states, as a rule of thumb, that the right choice here is a struct:

https://llvm.org/docs/CodingStandards.html#use-of-class-and-struct-keywords






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69930