24731, "bradcray", "Analysis of possibly-parallel vs. known-serial code sections and related optimizations", "2024-03-29T23:41:05Z"
This issue captures the longstanding idea of having a compiler pass that determines which code sections are provably going to be executed serially vs. those that are potentially going to be called in parallel settings; and then to develop optimizations that can leverage such information.
As a specific example, today, stdin, stdout, and stderr are locking channels to support parallel console IO from multiple tasks without having them step on one anothers' toes, as in our hello, world examples. If one wants top performance in a serial, IO-heavy section of code (as in the CLBG benchmarks), it's common to create non-locking variants of these channels and use those instead. But what if the compiler could automatically strength reduce such IOs in provable serial sections to cheaper, non-locking forms? Then every Chapel user would benefit, whether they knew about the ability to manually create such non-locking channels or not, and expert users would not need to go to the trouble of manually creating such non-locking versions.
I expect we could come up with many other optimizations (or warnings or hints) that would benefit from this information as well.