Hi! On 2022-12-16T15:51:35+0100, Tom de Vries via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > On 9/21/22 09:45, Chung-Lin Tang wrote: >> 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
Also: my 2022-03-17 report in <https://gcc.gnu.org/PR99555> "[OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs": <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555#c13>. >> 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. I'm happy to confirm that this also does resolve the PR99555 issue mentioned above, so please do reference PR99555 in the commit log. >> Is this okay for trunk? > Yes, LGTM, please apply (after the other one). > > Thanks for addressing this. Thanks, Chung-Lin and Tom! >> (also suggest backporting to GCC12 branch, if performance regression can >> be considered a defect) > > That's ok, but wait a while after applying on trunk before doing that, > say a month. Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
