See my responses below.
>> My concern with this patch's change to passByRef() is that flattening
>> will pass large records by value. Which is exactly what our 'const'
>> intent is intended to eliminate. Seems inconsistent to me.
>
> I don't think that's right. We pass blank and const records by
> reference at the C level; as far as I know, there's no need to change
> the formal type of the argument to 'ref' (as this routine is attempting
> to do) in order to get this effect. As we've discussed, the Chapel IR
> is intended to be representing Chapel semantics (at least at this point),
> not C semantics.
>
> I can spot-check a specific example/scenario to verify that this is
> still the case if you have one in mind.
I do not claim to follow the "C vs. Chapel-level" paragraph above. In
any case, the example is this:
record R { var x: int; }
outer();
proc outer() {
const r: R;
inner();
proc inner() {
writeln(r);
}
}
If R is large (which the compiler currently does not discern), inner()
in the generated code should be getting a pointer argument, rather than
a struct argument.
BTW in the following example RVF on the trunk fails to forward 'r' even
though it should. Maybe your patch fixes that.
record R { var x: int; }
proc test() {
const r: R;
var i$: sync int;
on Locales[numLocales-1] {
i$ = 1;
writeln(r);
}
}
test();
> Recall that the last time we discussed this broadly as a group, it was
> decided that the 'const'-ness of an argument was only supposed to
> reflect the callee's intentions for that argument, not the caller's. To
> know that the actual is const, you'd need to analyze the callsites and
> can't expect to see this in the intent's bitmask (though we could store
> it in some compiler-generated meta-information created by an analysis
> pass). The fact that I was checking the bit expecting to know something
> about the actual was my mistake and the reason that I'm now testing and
> planning to commit a more specific check for CONST_IN.
OK, if we are to stick with this language definition, then
(a) we should distinguish, in the intent bitmask, the bit that says "do
not modify this formal" from the bit that says "this formal does not
change", and
(b) in addition to 'const ref', we should provide an intent that (1) has
the run-time efficiency of 'ref' and (2) assures the callee that the
formal does not change. The actuals for such intent must be 'const'
variables or formals of guaranteed-unchanged ref intents.
Vass
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
