Hi Hui -
A forall is creating parallelism based on iterators defined in
the module code. Those iterators typically have a coforall in them.
The goal is that forall is useful for data parallelism, where the
user doesn't really care exactly how many tasks execute the loop. A
coforall is different - the user is insisting on a separate task
for each loop body, so that the loop iterations could communicate
with each other (for example).
In this case, I'd say it is probably correct to see line numbers
in the internal modules related to the code that implements the
iterators driving a forall loop. The internal coforall would correspond
to something inside the internal modules in that case.
Is there some reason that is not sufficient for your use?
I'd expect the loop body corresponding to the user's computation
to reflect the obvious line numbers though... e.g.
forall x in A {
writeln("x is ", x); // <- this statement should have an accurate line#
}
That's definitely a bug if it's not the case...
-michael
On 10/30/15, 12:15 PM, "Hui Zhang" <wayne.huizh...@gmail.com> wrote:
>Hello,
>
>
>I'm wondering what is exactly the difference in translating/implementing
>the ''forall'' loop against "coforall" ?
>
>
>Since in my experiment, if I use forall loop, either the intermediate
>llvm or c code output will have a "coforall_fn_chpl" function that
>contains the actual computation within the
> user code's forall body, but that function is wrongly mapped to the
>internal module source code; however, if I use coforall(nothing else
>changed), same coforall_fn_chpl will be generated(everything looks the
>same as before) and it will be correctly mapped
> back to the user code ! Now, you can find "coforall_fn_chpl" function
>in the user code module if you check the AST for user code, but before,
>you couldn't find that function in user's AST, even though it was there
>in the llvm bit code !
>
>
>Any ideas ? Thanks
>
>
>
>On Thu, Oct 29, 2015 at 12:17 PM, Hui Zhang
><wayne.huizh...@gmail.com> wrote:
>
>okay...thanks for the info !
>
>
>I'll definitely let you know when I find out the bug.
>
>
>
>On Thu, Oct 29, 2015 at 12:09 PM, Brad Chamberlain
><br...@cray.com> wrote:
>
>
>Hi Hui --
>
>Chiming in on this part:
>
>On Thu, 29 Oct 2015, Michael Ferguson wrote:
>
>
>The compiler generally uses a global variable for the file/line.
>This variable is set with SET_LINENO and the file/line from it are
>stored in each new AST node.
>
>If you have identified the AST node with the wrong line number, you
>can get its id number (ast->id) and instruct the compiler to
>call gdbShouldBreakHere when that id is created with --break-on-id.
>It's possible that some code adding AST elements called
>SET_LINENO with the wrong argument.
>
>
>
>
>If you find the source of the AST creation that has the wrong
>filename/line#, please let us know. We're trying to shake out these
>cases over time as best we can, for obvious reasons.
>
>
>One other thing I'll mention is that oftentimes, an AST node that you're
>looking at in codegen has been copied a few times before getting there,
>so its creation point will be a copy of another AST node which also had
>the wrong filename/line#. So then I usually
> re-run with --break-on-id, chasing the copies upstream until I find the
>original creation point.
>
>-Brad
>
>
>
>
>
>
>
>
>
>--
>Best regards
>
>
>Hui Zhang
>
>
>
>
>
>
>
>
>--
>Best regards
>
>
>Hui Zhang
>
>
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
Chapel-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/chapel-developers
