Hello, Michael Okay....that makes a lot more sense now
In my case, as your example, I need a nice stack trace when a sample fell on that "writeln", but now it'll give me something like this (assume file is user.chpl, forall is on line #1): wrap_coforall_fn (user.chpl : 1) -> coforall_fn (ChapelRange.chpl: 2) -> writeln (..) I expected it to be something like: wrap_coforall_fn(user.chpl: 1) -> coforall_fn(user.chpl: 2) -> writeln(..) So if the filename is internal modules, then it'll be difficult for me to transfer data along the stack since my previous analysis only concerns about user code... Another question: why the line# of the frame I got is "correct"(right line# in the user code, here '2') when the file/module is internal module ? Thanks On Fri, Oct 30, 2015 at 12:22 PM, Michael Ferguson <[email protected]> wrote: > 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" <[email protected]> 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 > ><[email protected]> 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 > ><[email protected]> 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 > > > > > > -- Best regards Hui Zhang
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
