On Tue, 2 Jan 2024 23:21:21 +0800 Chung-Lin Tang <clt...@pllab.cs.nthu.edu.tw> wrote:
> To Julian, there is a patch to the middle-end neutering, a hack > actually, that detects SSA_NAMEs used in reduction array MEM_REFs, > and avoids single->parallel copying (by moving those definitions > before BUILT_IN_GOACC_SINGLE_COPY_START). This appears to work > because reductions do their own initializing of the private copy. It looks OK to me I think (bearing in mind your following paragraph, of course!). I wonder though if maybe non-SSA (i.e. addressable) variables need to be handled also, i.e. parts like this: + /* For accesses of variables used in array reductions, instead of + propagating the value for the main thread to all other worker threads + (which doesn't make sense as a reduction private var), move the defs + of such SSA_NAMEs to before the copy block and leave them alone (each + thread should access their own local copy). */ + for (gimple_stmt_iterator i = gsi_after_labels (from); !gsi_end_p (i);) + { + gimple *stmt = gsi_stmt (i); + if (gimple_assign_single_p (stmt) + && def_escapes_block->contains (gimple_assign_lhs (stmt)) + && TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME) are only handling SSA-converted variables. But maybe that's OK? > As we discussed in our internal calls, the real proper way is to > create the private array in a more appropriate stage, but that is too > long a shot for now. The changes here are needed at least for some > -O0 cases (when under optimization, propagation of the private > copies' local address eliminate the SSA_NAME and things actually just > work in that case). So please bear with this hack. HTH, Julian