[Openmp-commits] [PATCH] D64808: [OPENMMP] Resolve lost LoopTripCnt for subsequent loops in same thread.

Alexey Bataev via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Tue Jul 16 12:23:23 PDT 2019


ABataev added inline comments.


================
Comment at: libomptarget/test/offloading/looptripcnt.c:38
+  printf("num_threads %d num_teams %d\n", num_threads[0], num_teams[0]);
+// DEBUG: loop trip count is 128
+  return 0;
----------------
ronlieb wrote:
> ABataev wrote:
> > ronlieb wrote:
> > > ABataev wrote:
> > > > I think, instead of the debug messages better to check the results of the `printf`s.
> > > I initially thought about that, but I am worried that depending on what architecture you run on it might produce different numbers of teams, if the thread limit was a lot smaller than on a gpu for example.
> > > 
> > > but what I am really trying to test is that we found the loopTripCount to pass into the runtime.  
> > > 
> > > if you strongly prefer that I still do so, I will be happy to change the test. I would of course still keep the DP message for diagnostic purposes down the road.
> > It is always better to check the real results rather than debug messages. If you could write a test, which is able to provide a stable check, then do this.
> ok, so I spent some time trying to do this. The issue I am encountering is 
> that the behavior that needs to be verified is that we properly find the loop trip count in  the function 'target' within omptarget.cpp. This is then passed along to function __tgt_rtl_run_target_team_region in plugins.cpp which  "may" choose to modify the blocksPerGrid or not. So depending on your target, you may see different numbers of teams active if you query omp_get_num_teams().  The observed behavior on different hosts is tenuous at best in determining if loop_trip_count was properly found. The point of this test is to make sure we dont loose the loop_trip_count. In this situation i think it best to catch the problem in Debug build/test where we can explicitly observe the DP message.
> 
Then better to check for the debug message, I think. Other opinions?


Repository:
  rOMP OpenMP

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

https://reviews.llvm.org/D64808





More information about the Openmp-commits mailing list