[PATCH] D73285: [OpenMP][OMPIRBuilder][BugFix] Handle Unreachable Finalization blocks in `parallel` generation

Fady Ghanim via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jan 29 06:17:25 PST 2020


fghanim marked an inline comment as done.
fghanim added inline comments.


================
Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:661
+    AfterIP = InsertPointTy(ForkBB, ForkBB->end());
+  }
 
----------------
jdoerfert wrote:
> fghanim wrote:
> > jdoerfert wrote:
> > > Why do we need all of this? Can't we just *not do it* instead? This is code complexity that we should avoid.
> > Depends. 
> > If we want to conform with the way things are done in clang; namely, not have unreachable blocks, then yes we need to do this. If not, then no, nothing needs to change. An optimization pass will be executed at some point later that should clean all that up.
> > 
> > However, we should be careful, for example, The lit test for `critical` checks that no basic blocks were generated from the rest of the body that comes after the infinite loop. So if the choice is to not conform with clang, then we should keep an eye on these lit tests, and disable such checks for the OMPBuilder.
> > If we want to conform with the way things are done in clang;
> 
> It's not like we introduce much extra code, break anything, or make the final result different.
> 
> 
> >  If not, then no, nothing needs to change. An optimization pass will be executed at some point later that should clean all that up.
> 
> Let's go with that solution and keep this code here simple, less error prone, and easier to manage.
> 
> 
> > However, we should be careful, for example, The lit test for critical checks that no basic blocks were generated from the rest of the body that comes after the infinite loop. So if the choice is to not conform with clang, then we should keep an eye on these lit tests, and disable such checks for the OMPBuilder.
> 
> We already do things different and that will only become more evident (TRegions!). For example, to simplify this code we do *not* cache runtime calls (anymore). That is we emit a new get_thread_id call every time. (We know the OpenMPOpt pass will clean it up eventually.) I get that the tests change and for a while we will have clang and OMPBuilder check lines. Though, once the clang CG is gone there is arguably no difference anymore because the OMPBuilder behavior is then the default. As soon as we have the privatization parts properly hooked up we can even start running the OMPBuilder by default and soon after removing clang CG parts. If anything, we should modernize the clang tests as they are a constant critique point that hinders outside involvement. We could start using the llvm/utils/update_XXXX_checks scripts for example. We could also minimize the check lines and focus on the most important bits only. (I prefer the update scripts with the pending extensions, e.g., D69701)
> 
In that case, This revision is not necessary. The only fix needed is the branch erasure/creation change in the body CallBack (a bit more on this later), all the rest including the tests is not necessary. The only tests needed are already being done by the llvm verifier, which already reports if a BB is used by an orphan branch sticking around, or if a BB contains more than one terminator.

Regarding the issue of the branch, given that our finalization and body callbacks are very similar across different directives (Parallel, master, critical), the plan as we discussed on D72304 , is to write helper functions/class that we could use instead. So whoever, ends up writing that should make sure to include the branch changes, which makes them here redundant.

So, in the interest of everyone's time, my suggestion is to abandon this revision entirely for now, and just make sure that the implementation of these helper functions takes care of this everywhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73285





More information about the cfe-commits mailing list