Chapel: array.domain and in intent

Created on 4 Aug 2020  路  5Comments  路  Source: chapel-lang/chapel

What should this program do?

var D = {1..10};
var A:[D] int;

proc f(in dom) {
  D = {1..3};
  writeln("D is ", D);
  writeln("dom is ", dom);
}

writeln("passing D");
D = {1..10};
f(D);

writeln("passing A.domain");
D = {1..10};
f(A.domain);

It currently prints out

passing D
D is {1..3}
dom is {1..10}
passing A.domain
D is {1..3}
dom is {1..3}

Should it print out

passing D
D is {1..3}
dom is {1..10}
passing A.domain
D is {1..3}
dom is {1..10}

?

Language Bug Design

Most helpful comment

Yeah, I think it should definitely print out the second behavior. Would it not be sufficient to have _array.domain return a const ref to the _domain record representing the array's domain? (rather than introducing the notion of a domain view).

All 5 comments

The A.domain support is currently implemented with a runtime flag. In contrast, for most other types this is a compile time behavior. Could we migrate the A.domain functionality to be compile-time as well? That would mean that A.domain would return some sort of "domain view" type. It's unclear to me in what cases having it compile-time vs. runtime would matter. Of course, a difference in the type would be observable.

Yeah, I think it should definitely print out the second behavior. Would it not be sufficient to have _array.domain return a const ref to the _domain record representing the array's domain? (rather than introducing the notion of a domain view).

We could have _array.domain return a const ref to the _domain record but for the fact that it doesn't already exist because the _array record doesn't have a _domain record - rather it has an _instance that is an array implementation class that in turn has an instance of a domain implementation class.

I have been thinking it might be possible for the compiler to mark _getDomain with pragma "no copy return" and then add compiler logic to make sure something like return A.domain results in a copy. (Also pragma "fn returns iterator").

These questions are coming from a desire to get rid of chpl__unref and chpl__unalias if possible. I am thinking it would be possible to detect cases where an initCopy returns a different type and just leave the initCopy present in that case.

I have been thinking it might be possible for the compiler to mark _getDomain with pragma "no copy return" and then add compiler logic to make sure something like return A.domain results in a copy. (Also pragma "fn returns iterator").

There is one case when this might have an unintended effect. Something like this:

var x = if option then A.domain else {1..100};

If we rely on the compile-time only approach, then this will result in a copy even for the case of option==false. The reason is the compiler will not know which branch is taken. It is possible that we could resolve this by adjusting the implementation of if-expressions. (Namely, the if-expression could do the copying inside of the conditional - this is what we do for returns in conditionals).

I think this is acceptable for now because we haven't yet tackled trying to get the copies involved in a domain (really, associative domain) optimized as we have for arrays (https://github.com/Cray/chapel-private/issues/962 covers that TODO). And, I would really like to remove the runtime handling in chpl__unalias and the domains are the only thing that currently use it.

That seems like a reasonable tradeoff to me.

Was this page helpful?
0 / 5 - 0 ratings