Hi! On 2022-10-14T13:38:55+0000, Julian Brown wrote: > The GCN backend uses a heuristic to determine whether to use FLAT or > GLOBAL addressing in a particular (offload) function: namely, if a > function takes a pointer-to-scalar parameter, it is assumed that the > pointer may refer to "flat scratch" space, and thus FLAT addressing must > be used instead of GLOBAL. > > I came up with this heuristic initially whilst working on support for > moving OpenACC gang-private variables into local-data share (scratch) > memory. The assumption that only scalar variables would be transformed in > that way turned out to be wrong. For example, prior to the next patch in > the series, Fortran compiler-generated temporary structures were treated > as gang private and moved to LDS space, typically overflowing the region > allocated for such variables. That will no longer happen after that > patch is applied, but there may be other cases of structs moving to LDS > space now or in the future that this patch may be needed for. > > Tested with offloading to AMD GCN. I will apply shortly (to og12). Thanks. I've verified that this does resolve PR105421 "GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'" and have thus added PR105421 tags to your commit log, and with that pushed to master branch commit 7c55755d4c760de326809636531478fd7419e1e5 "amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421]", see attached. 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