20156, "e-kayrakli", "How should we handle module-scope variables w.r.t GPU support in the short term?", "2022-07-05T16:48:50Z"
This issue is to capture a limitation (and discuss whether we should have a not-so-quick-but-dirty solution for it) that might be hit commonly by the early-testers of our GPU support.
Module-scope variables are problematic with CHPL_COMM!=none. We make them wide and if a gpuizable loop accesses it, we add a narrow argument to the kernel but pass the wide thing to it. This compiles, surprisingly, but generates junk results. This is an unimplemented feature, because as far as I know none of us have spent enough time thinking on it. Arguably, when we have gpu-driven communication, this issue will be moot. Should we consider an earlier solution to this potentially confusing issue?
Another potential solution is to broadcast wide variables passed to GPU kernels. But that doesn't feel right, nor trivially-implementable.
As a side note, we've found out that if a loop calls a function that accesses a module-scope variable, that makes the loop non-gpuizable. I suspect that's a separate issue with our outliner, that, when fixed, that scenario will also bump into the same issue.