dyno: Initial resolution of `zip()` expressions and parallel iterators #24915

dlongnecke-cray · 2024-04-23T22:12:47Z

This PR introduces resolution of zip() expressions and resolution of parallel iterators for forall and [] loops.

For zip() expressions that appear as the iterand of a serial loop, the strategy is to resolve only serial iterators for each actual in the zip().

For zip() expressions that appear as the iterand of a forall loop, the strategy is to:

For the first actual (known as the leader), attempt to resolve a suitable leader iterator or error
For the leader and all remaining actuals (known as followers), attempt to resolve a suitable follower iterator or error

For [] loops, the strategy is similar, except serial iterators may be used as a substitute for the leader and followers IFF the leader iterator could not be resolved for the leader. If the leader iterator could be resolved, but e.g., its return type could not, then serial iterators will not be considered as fallbacks.

For iterands that are not zip() expressions, the "standalone" parallel iterator is preferred for parallel loops before attempting to resolve a leader/follower combo. As with zip(), forall loops will emit an error if no form of parallel iterator could be resolved. All other loops will fall back to serial iterators.

Thanks to @vasslitvinov for walking me through the semantics of zip() and parallel iterator resolution.

FUTURE WORK

Iterator forwarding for iterators in the internal modules (e.g., tag=tag, followThis=followThis)
Expand tests, handle error cases, attempt to resolve leader/follower/standalone iterators for standard/internal types
Consider adding an enum to TypedFnSignature expressing its iterKind
Set array types before resolving iterators instead of backpatching

Reviewed by @DanilaFe, @mppf. Thanks!

dlongnecke-cray · 2024-04-23T22:50:21Z

I'll fix the CI check failures tomorrow, have to head out for the night.

DanilaFe

I'm halfway through, a few comments, mostly minor changes within individual lines.

frontend/include/chpl/types/EnumType.h

frontend/lib/resolution/Resolver.cpp

dlongnecke-cray · 2024-04-24T21:18:59Z

Adding isSerialIterator isLeaderIterator isFollowerIterator and isStandaloneIterator as per your suggestion.

Signed-off-by: David Longnecker <[email protected]>

dlongnecke-cray · 2024-06-21T03:11:11Z

My PR has exposed a different bug in testLibrary.testHelloWorld that is causing the test to fail (so CI checks fail).

While here, also comment out the 'testHelloWorld' dyno test. Resolving parallel iterators has introduced some bugs that cause this test to fail. Re-add it when we think the dyno resolver is ready. Signed-off-by: David Longnecker <[email protected]>

DanilaFe

I had a straggler comment I apparently never submitted.

DanilaFe · 2024-04-26T02:08:26Z

frontend/lib/resolution/resolution-types.cpp

@@ -819,6 +820,33 @@ void TypedFnSignature::stringify(std::ostream& ss,
  ss << ")";
 }

+bool TypedFnSignature::
+isIterWithIterKind(Context* context, const std::string& iterKindStr) const {


I suggest using UniqueString for this after all because USTR comparisons are O(1) -- as opposed to O(n) for std::strings. They also require less allocations.

Signed-off-by: David Longnecker <[email protected]>

DanilaFe

Went over it again since I've not been ooking at it for a while. This looks very very slick. 👍

DanilaFe · 2024-06-27T22:47:30Z

frontend/lib/resolution/Resolver.cpp

+      if (it != m->end()) return it->second;
+    }
+  }
+  return QualifiedType(QualifiedType::VAR, UnknownType::get(rv.context));


For UnknownType, I think you need to set the kind to QualifiedYype::UNKNOWN.

IMO this would be better supported by a query. Seems like a fair amount of unnecessary work to redo & there will only be a handful of inputs and outputs to it.

DanilaFe · 2024-06-27T22:49:06Z

frontend/lib/resolution/Resolver.cpp

+  // Resolve iterators, stopping immediately when we get a valid yield type.
+  auto ret = [&]() -> IterDetails {


Are you doing this to make early return possible? I suggest extracting this into a helper and not defining an immediately-invoked lambda.

DanilaFe · 2024-06-27T22:50:49Z

frontend/lib/resolution/Resolver.cpp

+  bool needStandalone = iterKindStr == "standalone";
+  bool needLeader = iterKindStr == "leader";
+  bool needFollower = iterKindStr == "follower";


Use USTR("standalone") etc. here to make the comparison O(1) instead of O(n).

DanilaFe · 2024-06-27T22:53:11Z

frontend/lib/resolution/Resolver.cpp

+    ((fn->isParallelStandaloneIterator(context) && needStandalone) ||
+     (fn->isParallelLeaderIterator(context) && needLeader) ||
+     (fn->isParallelFollowerIterator(context) && needFollower) ||
+     (fn->isSerialIterator(context) && needSerial));


How can this be possible? I don't think we allow being able to write calls with user-provided tags.

Missed this - it is possible and is called iterator "forwarding" and is done in the internal modules. It should be an error in user code, though.

DanilaFe · 2024-06-27T22:57:34Z

frontend/lib/resolution/Resolver.cpp

-        cur.enterScope(loop);
+    if (!ret.isUnknownOrErroneous()) {
+      rv.handleResolvedCall(iterandRE, astForErr, ci, c,
+                            { { AssociatedAction::ITERATE, iterand->id() } });


Suspect the associated action needs to be different for turning foo() into foo(tag=follower)

I wouldn't worry about that right now; we aren't consuming the associated actions yet and will know more when we do. It might be sufficient because the resolved function should be saved here in the associated action.

DanilaFe · 2024-06-27T22:59:49Z

frontend/lib/resolution/resolution-types.cpp

+  if (!isIterator()) return false;
+
+  auto ik = types::EnumType::getIterKindType(context);
+  if (auto m = types::EnumType::getParamConstantsMapOrNull(context, ik)) {


Consider early return if this is nullptr to avoid nesting code.

DanilaFe · 2024-06-27T23:01:09Z

frontend/test/resolution/testLoopIndexVars.cpp

+#define ADVANCE_PRESERVING_SEARCH_PATHS_(ctx__) \
+  do { \
+    ctx__->advanceToNextRevision(false); \
+    setupModuleSearchPaths(ctx__, false, false, {}, {}); \


Strictly speaking this doesn't preserve them as much as it resets them to empty. A macro or method for this that truly preserves search paths would be nice.

I'll go ahead and rename the macro to something like "advance preserving standard modules".

mppf

Generally, this looks good. I'm happy to see Resolver::enter(const IndexableLoop* loop) broken up into helper functions.

I'd like you to address my feedback comments before merging; some of these are asking you to restructure some of the code, but I am not expecting these changes to be very hard since the computation will be the same.

Can you take a minute to try to add the early check for it being an array type? I am not expecting that is very hard. If it is hard, listing it as Future Work in the PR message would be good. I think we should try to do this sooner rather than later as I expect it'll be a compilation performance hit if we don't.

mppf · 2024-06-28T15:07:43Z

frontend/include/chpl/resolution/resolution-types.h

@@ -949,6 +955,9 @@ class TypedFnSignature {
                      const TypedFnSignature* parentFn,
                      Bitmap formalsInstantiated);

+  bool
+  isIterWithIterKind(Context* context, UniqueString iterKindStr) const;


Should we introduce an enum in the C++ code for this? The use of UniqueStrings is OK with me as well; but an enum would allow additional checking at compile-time (e.g. avoiding mis-spelling; and in some cases we can write switch statements and have the compiler check we covered all cases).

mppf · 2024-06-28T15:08:31Z

frontend/include/chpl/types/EnumType.h

+      in 'et' to each constant represented as a param value.
+      If there are multiple enum constants with the same name (which
+      means the AST is semantically incorrect), then only the first
+      constant is added to the map. */


This docs string should say in what situation it would return nullptr.

mppf · 2024-06-28T15:14:10Z

frontend/lib/types/EnumType.cpp

+      auto k = UniqueString::get(context, elem->name().str());
+      auto it = ret.find(k);
+      if (it != ret.end()) continue;
+      ret.emplace_hint(it, std::move(k), std::move(qt));


IMO it's clearer to use insert instead of find/emplace_hint. Also we use this insert pattern in many other places in dyno, so using it here would make this code easier to follow for anybody looking at lots of dyno code.

insert can return a pair, where the second element of that pair indicates if insertion took place. If the map already had the element, insert won't insert anything, and so that second element will be false.

mppf · 2024-06-28T15:15:56Z

frontend/lib/resolution/resolution-types.cpp

+
+    auto it = m->find(iterKindStr);
+    if (it != m->end()) {
+      bool isFollowerIterKind = iterKindStr == "follower";


iterKindStr == USTR("follower");

mppf · 2024-06-28T15:21:54Z

frontend/lib/resolution/resolution-types.cpp

@@ -843,6 +844,33 @@ void TypedFnSignature::stringify(std::ostream& ss,
  ss << ")";
 }

+bool TypedFnSignature::
+isIterWithIterKind(Context* context, UniqueString iterKindStr) const {


This will be unnecessarily slow in the context of isSerialIterator where it is called multiple times with different kind strings.

Let's instead make a function to return the iterator kind for iterators. Then the TypedFnSignature would be doing things like iterKind(context) == USTR("leader").

Also, IMO it is worthwhile to make some kind of representation of the iterator kind part of TypedFnSignature itself. That would prevent the work of repeatedly computing this information. I don't view this as a strict requirement, but if it appeals to you, let's go ahead with it. (If you do this, please add an enum for the compiler's representation of iterator kinds). Of course, an alternative way would be use a query to compute the iterKind for a const TypedFnSignature*.

I am torn about whether or not to add an enum or just compute it. I'm not sure the performance cost of computing it repeatedly will be that high or significant. I agree this particular code can be improved.

mppf · 2024-06-28T15:46:31Z

frontend/lib/resolution/Resolver.cpp

+  Context* context = rv.context;
+
+  if (mask == IterDetails::NONE || rv.scopeResolveOnly) {
+    iterand->traverse(rv);


Probably deserves a comment here about why we need to traverse the iterand in this case.

mppf · 2024-06-28T15:50:27Z

frontend/lib/resolution/Resolver.cpp

-                MSC.only().fn()->untyped()->kind() == uast::Function::Kind::ITER;
+  // Resolve the iterand but suppress errors for now. We'll reissue them
+  // next, possibly suppressing a "NoMatchingCandidates" for the iterand if
+  // our injected call is successful.


Why suppress errors here? That seems odd to me. I would think, if we have for i in abc() or forall j in def() then an error in resolving abc() or def() would be fatal. Is the issue that, def might have a standalone iterator but not a serial iterator? Would that be better handled by resolving interior parts of a call (e.g. forall j in a(b(c())) we resolve b(c()) but delay resolving a() for now.

It seems to me that we could do this by simply traversing the children of iterand here before we proceed. The runAndTrackErrors stuff is cool but I think it has performance implications.

I just needed to resolve the iterand's type fully before I could make any decisions about it. It could be an iterator call. It could be as you say, a type with a standalone iterator but not a serial, in which case we need to inject the arguments and try again.

This is one way to do it, but I agree about the potential negative performance impact. Another option could be to add some sort of bool doNotEmitCallErrors flag to the Resolver. I tried to get that to work for a bit but I wasn't happy with it.

I will add a future work item about exploring an alternative to runAndTrackErrors.

mppf · 2024-06-28T15:54:22Z

frontend/lib/resolution/Resolver.cpp

+  bool wasIterandTypeResolved = !iterandRE.type().isUnknownOrErroneous();
+  bool wasIterResolved = fn && fn->isIterator();
+  bool wasMatchingIterResolved = wasIterResolved &&
+    ((fn->isParallelStandaloneIterator(context) && needStandalone) ||


IMO this code would be more efficiently written if it computes the iterator tag and then does comparisons including needStandalone etc.

auto iteratorTag = fn->iteratorTag(context); if ((iteratorTag == USTR("standalone") && needStandalone) || ...

(of course it would look different if you add that enum).

mppf · 2024-06-28T15:59:29Z

frontend/lib/resolution/Resolver.cpp

-        cur.enterScope(loop);
+    if (!ret.isUnknownOrErroneous()) {
+      rv.handleResolvedCall(iterandRE, astForErr, ci, c,
+                            { { AssociatedAction::ITERATE, iterand->id() } });


I wouldn't worry about that right now; we aren't consuming the associated actions yet and will know more when we do. It might be sufficient because the resolved function should be saved here in the associated action.

mppf · 2024-06-28T16:05:06Z

frontend/lib/resolution/Resolver.cpp

+
+  // TODO: What would it take to make backpatching of array types happen
+  // _before_ / without resolving an iterator? Currently we rely on iterator
+  // resolution to resolve the iterand for us.


I thought that we only needed to detect if elements yielded by the loop expression are types rather than values? Also it checks something about there being a domain involved. Seems like it'd be easy enough to filter these earlier. Am I wrong about something?

I'll change the stale TODO.

Signed-off-by: David Longnecker <[email protected]>

dlongnecke-cray · 2024-07-04T00:12:37Z

Hello @mppf @DanilaFe. I believe I've responded to all of your feedback. I've added some TODOS to the future work part of the PR message.

Signed-off-by: David Longnecker <[email protected]>

DanilaFe reviewed Apr 24, 2024

View reviewed changes

dlongnecke-cray added 9 commits June 20, 2024 17:11

Begin effort of resolving 'zip()' and parallel iterators

9fa8dfa

Signed-off-by: David Longnecker <[email protected]>

Stabilize zip() and parallel iterator resolution, all tests passing

e9854ce

Signed-off-by: David Longnecker <[email protected]>

Add tests for parallel standlone iterators

5c0b102

Signed-off-by: David Longnecker <[email protected]>

Avoid speculation if the iterand does not look like a call

702898a

Signed-off-by: David Longnecker <[email protected]>

Remove comments, adjust formatting, add factory for tests

281723b

Signed-off-by: David Longnecker <[email protected]>

Attempt to fix failing CI checks (1)

798009a

Signed-off-by: David Longnecker <[email protected]>

Respond to reviewer feedback (1)

5d56442

Signed-off-by: David Longnecker <[email protected]>

Always speculatively resolve, add TODO about removing speculation

d229388

Signed-off-by: David Longnecker <[email protected]>

Add new "driver" function that only resolves the iterand once

24d9319

Signed-off-by: David Longnecker <[email protected]>

dlongnecke-cray force-pushed the dyno-resolve-zip branch from 92a3803 to 24d9319 Compare June 21, 2024 03:03

DanilaFe reviewed Jun 27, 2024

View reviewed changes

dlongnecke-cray added 2 commits June 27, 2024 15:27

Respond to reviewer feedback (2)

82a6788

Signed-off-by: David Longnecker <[email protected]>

Adjust how iterator policy is set when resolving loop iterands

e338b79

Signed-off-by: David Longnecker <[email protected]>

DanilaFe reviewed Jun 27, 2024

View reviewed changes

mppf approved these changes Jun 28, 2024

View reviewed changes

Respond to reviewer feedback (3)

e8fdd3e

Signed-off-by: David Longnecker <[email protected]>

Attempt to silence failing CI checks (2)

8f5f415

Signed-off-by: David Longnecker <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dyno: Initial resolution of `zip()` expressions and parallel iterators #24915

dyno: Initial resolution of `zip()` expressions and parallel iterators #24915

dlongnecke-cray commented Apr 23, 2024 •

edited

Loading

dlongnecke-cray commented Apr 23, 2024

DanilaFe left a comment

dlongnecke-cray commented Apr 24, 2024

dlongnecke-cray commented Jun 21, 2024

DanilaFe left a comment

DanilaFe Apr 26, 2024

DanilaFe left a comment

DanilaFe Jun 27, 2024

mppf Jun 28, 2024

DanilaFe Jun 27, 2024

DanilaFe Jun 27, 2024

DanilaFe Jun 27, 2024

dlongnecke-cray Jul 3, 2024

DanilaFe Jun 27, 2024

mppf Jun 28, 2024

DanilaFe Jun 27, 2024

DanilaFe Jun 27, 2024

dlongnecke-cray Jun 27, 2024

mppf left a comment

mppf Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

dlongnecke-cray Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

dlongnecke-cray Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

mppf Jun 28, 2024

dlongnecke-cray Jun 28, 2024

dlongnecke-cray commented Jul 4, 2024

		// Resolve iterators, stopping immediately when we get a valid yield type.
		auto ret = [&]() -> IterDetails {

dyno: Initial resolution of zip() expressions and parallel iterators #24915

Are you sure you want to change the base?

dyno: Initial resolution of zip() expressions and parallel iterators #24915

Conversation

dlongnecke-cray commented Apr 23, 2024 • edited Loading

dlongnecke-cray commented Apr 23, 2024

DanilaFe left a comment

Choose a reason for hiding this comment

dlongnecke-cray commented Apr 24, 2024

dlongnecke-cray commented Jun 21, 2024

DanilaFe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanilaFe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mppf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dlongnecke-cray commented Jul 4, 2024

dyno: Initial resolution of `zip()` expressions and parallel iterators #24915

dyno: Initial resolution of `zip()` expressions and parallel iterators #24915

dlongnecke-cray commented Apr 23, 2024 •

edited

Loading