Add static analysis to avoid adding slow followers in some cases

[e-kayrakli]

This PR adds a static analysis to detect whether zippered distributed arrays
share the same domain and thus can leverage the fast follower optimization.

This is a small part of what I attempted at #16001.

This PR also rearranges the newly-added autoLocalAccess.cpp to make it more
general purpose.

Summary of changes:

• Add staticFastFollowerAnalysis to autoLocalAccess.cpp
• Do some refactor on that file:
  • Rename to preNormalizeOptimizations.cpp
  • Put function declarations in the beginning of the file
  • Add a function doPreNormalizeArrayOptimizations to handle automatic local
    access and fast follower analysis right before normalization.

Although the main motivation for this PR was to reduce the compilation time
overheads, in some of the benchmarks I have seen that clones removed by this PR
to constitute only a small partion of those extra clones. #16001 gives an idea
of what needs to be done to remove a larger number of copies, and I hope to
revisit that effort soon.

Test:

• add a test to lock the behavior
• standard
• gasnet

[ronawho]

Can you give some examples of which cases you expect to be optimized?

For the simplified stream example:

use BlockDist;

config const m = 1000, alpha = 3.0;
config param promoted = false;

const Space = {1..m} dmapped Block({1..m});
var A, B, C: [Space] real;

if promoted {
  A = B + alpha * C;
} else {
  forall (a, b, c) in zip(A, B, C) do
    a = b + alpha * c;
}

I see the number of generated lines drop ~2.5K from 61,456 to 58,669 for the non-promoted case, which is great. (chpl stream.chpl --fast --savec gen && wc -l gen/* | grep total)

I don't see any change for the promoted case, and curiously I only an 850 line reduction for the real stream.

It's not surprising that the promoted case will require more work, but it did seem odd that the real stream didn't show much change.

[e-kayrakli]

I see similar behavior on the snippet. And as you said, reworking promotion is the next step. It was one of the things I had tried in the prior PR but couldn't get it working in a reasonable amount of time.

As for the real stream, this PR removes one dynamic check, but leaves the one in verifyResults. This is because (based on my experience in auto localAccess optimization):

• verifyResults is a generic function
• The loop duplication happens too late that we instantiate verifyResults first, during which we lose the information that the forall loop is amenable to fast follower optimization, so we go back to the old method of doing dynamic checks.

I have had similar problems with generic function instantiation when working on auto localAccess, but in its current status, all the duplication occurs before normalize, and we use special primitives to mark accesses local. So, we don't really need to carry any information when duplicating FnSymbols during function instantiation.

I still haven't cleared my head about how to refactor fast followers, and my reflex is to have it similar to how --auto-local-access works: do all the cloning prenormalize, prune some stuff out during resolve. I am not sure how easy it is to do that without changing forall to two nested fors with leaders and followers as early as normalization, though.

[ronawho]

"if the compiler can call it" -> "if the compiler can prove it's safe"?

[ronawho]

Minor, but I don't find the name particularly helpful. Maybe preNormalizeArrayOptimizations?

I think it's worth calling out that it's pre-normalize since source level semantics are important for these optimizations, but wonder if it'd be helpful to specify a little more.

[ronawho]

Leftover debug code, or is this meant to count the number of dynamic checks in the generated code?

[e-kayrakli]

This is my attempt to make sure that there is no dynamic check call in the generated code. Do you have a better approach in mind?

[ronawho]

Oh, duh -- gotcha. This makes sense, I was just confused by which file it was redirecting too. $2 is the name of the logfile, so you should just be able to do grep dynamicFastFollow c_code/staticCheck.c >> $2

Longer term, I wonder if there's a more general way to do this that would work for llvm. The only thing that comes to mind is a compilerWarning or something in the slow follower, but that either means adding a test distribution (which seems like a lot of code) or introducing a param protected warning in block, which feels wonky.

[e-kayrakli]

I have toyed with two different approaches that I believe can also work with LLVM:

• Hijack the distribution's follower in the test code, do a writeln, forward to the actual follower. I implemented something similar to this here
• Instead of grepping the generated code, grep something in the AST dump. Likely the dump of codegen.

[e-kayrakli]

@ronawho -- I interpreted your feedback as you are fine with the rest of the implementation and merged it to avoid doing that close to the weekend. Let me know if you have any post-merge feedback when you come back. (Including "I totally hated this, just revert it back")

[ronawho]

I interpreted your feedback as you are fine with the rest of the implementation and merged it to avoid doing that close to the weekend.

Yup, you interpreted correctly, I meant to approve this before taking off but I forgot.

Let me know if you have any post-merge feedback when you come back. (Including "I totally hated this, just revert it back")

Nope, looks great. This is something I've been wanting to do for a long time, but had no idea how to tackle it myself so I'm really excited to see progress on this.