Ping.
On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote: > Hi Tom, > I had a patch submitted earlier, where I reported that the current way of > implementing > barriers in libgomp on nvptx created a quite significant performance drop on > some SPEChpc2021 > benchmarks: > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600818.html > > That previous patch wasn't accepted well (admittedly, it was kind of a hack). > So in this patch, I tried to (mostly) re-implement team-barriers for NVPTX. > > Basically, instead of trying to have the GPU do CPU-with-OS-like things that > it isn't suited for, > barriers are implemented simplistically with bar.* synchronization > instructions. > Tasks are processed after threads have joined, and only if team->task_count > != 0 > > (arguably, there might be a little bit of performance forfeited where earlier > arriving threads > could've been used to process tasks ahead of other threads. But that again > falls into requiring > implementing complex futex-wait/wake like behavior. Really, that kind of > tasking is not what target > offloading is usually used for) > > Implementation highlight notes: > 1. gomp_team_barrier_wake() is now an empty function (threads never "wake" in > the usual manner) > 2. gomp_team_barrier_cancel() now uses the "exit" PTX instruction. > 3. gomp_barrier_wait_last() now is implemented using "bar.arrive" > > 4. gomp_team_barrier_wait_end()/gomp_team_barrier_wait_cancel_end(): > The main synchronization is done using a 'bar.red' instruction. This > reduces across all threads > the condition (team->task_count != 0), to enable the task processing down > below if any thread > created a task. (this bar.red usage required the need of the second GCC > patch in this series) > > This patch has been tested on x86_64/powerpc64le with nvptx offloading, using > libgomp, ovo, omptests, > and sollve_vv testsuites, all without regressions. Also verified that the > SPEChpc 2021 521.miniswp_t > and 534.hpgmgfv_t performance regressions that occurred in the GCC12 cycle > has been restored to > devel/omp/gcc-11 (OG11) branch levels. Is this okay for trunk? > > (also suggest backporting to GCC12 branch, if performance regression can be > considered a defect) > > Thanks, > Chung-Lin > > libgomp/ChangeLog: > > 2022-09-21 Chung-Lin Tang <clt...@codesourcery.com> > > * config/nvptx/bar.c (generation_to_barrier): Remove. > (futex_wait,futex_wake,do_spin,do_wait): Remove. > (GOMP_WAIT_H): Remove. > (#include "../linux/bar.c"): Remove. > (gomp_barrier_wait_end): New function. > (gomp_barrier_wait): Likewise. > (gomp_barrier_wait_last): Likewise. > (gomp_team_barrier_wait_end): Likewise. > (gomp_team_barrier_wait): Likewise. > (gomp_team_barrier_wait_final): Likewise. > (gomp_team_barrier_wait_cancel_end): Likewise. > (gomp_team_barrier_wait_cancel): Likewise. > (gomp_team_barrier_cancel): Likewise. > * config/nvptx/bar.h (gomp_team_barrier_wake): Remove > prototype, add new static inline function.
