Remove old reduction "tuning" from OpenMP Target variants #484
Conversation
…rm-ompt-reduction-tunings
I don't know how this code compiled.
| RAJA::forall<RAJA::omp_target_parallel_for_exec<threads_per_team>>( | ||
| RAJA::RangeSegment(ibegin, iend), | ||
| RAJA::expt::Reduce<RAJA::operators::plus>(&tsum), | ||
| [=] (Index_type i, Real_type& sum) { |
There was a problem hiding this comment.
Real_type& sum would need to be RAJA::expt::ValOp<Real_type, RAJA::operators::plus> & sum if we are pulling in the latest changes from RAJA/develop.
There was a problem hiding this comment.
We are not on RAJA develop yet. That will come later. One chunk of changes at a time.
| m_vmin = RAJA_MIN(m_vmin, static_cast<Int_type>(tvmin)); | ||
| m_vmax = RAJA_MAX(m_vmax, static_cast<Int_type>(tvmax)); |
There was a problem hiding this comment.
I'm sure there's a good reason, but why are we doing min and max operations outside of the forall here?
There was a problem hiding this comment.
Technically, it shouldn't matter when the kernel runs multiple times, but we want to make sure we are not just seeing the result from the last run through the kernel. This change was not made in this PR. It's been like that since the beginning.
There was a problem hiding this comment.
Ok, this looks fine because we're using the macros on integer types. If this were inside a lambda, we'd need to use .min() on the ValOp type in the near future.
There was a problem hiding this comment.
Yup. Those changes will be coming.
Summary