[m-dev.] --warn-non-tail-recursion and deep profiling

[Paul Bone]

On Wed, Mar 02, 2016 at 12:33:22PM +1100, Julien Fischer wrote:
> 
> Hi Paul,
> 
> On Wed, 2 Mar 2016, Paul Bone wrote:
> 
> >On Wed, Mar 02, 2016 at 10:13:24AM +1100, Julien Fischer wrote:
> >>
> >>Hi,
> >>
> >>Was it intended that --warn-non-tail-recursion should emit warnings
> >>in deep profiling grades?  Since those grades disable tail recursion
> >>you obviously get a warning about every recursive predicate.
> >
> >Not specifically.
> >
> >Because this is disabled by default simply enabling deep profiling won't
> >cause these warnings.  A user giving both options on the command line will
> >very quickly figure out what is happening, but if --warn-non-tail-recursion
> >is specified in a Mercury.options file, especially if it's setup by another
> >developer on a team, then enabling --deep-profiling might cause some
> >surprise.
> 
> That is the case I'm looking at.  Specifically, I'm looking at the
> "failure" of the test case invalid/require_tailrec_2 in the grade
> none.gc.profdeep.trseg.stseg.  We get additional warnings for this test
> case because tail recursion is disabled.  There are various ways to
> avoid this failure (e.g. extra expected output, don't run the test in
> profdeep grades); I'm trying to determine which one to use here.

I suggest not running these tests with the profdeep grade component.

> >I think that the question is: which surprise is better?  Lots of
> >warnings
> 
> It's lots of warnings that are *not* present in non profdeep grades.
> Also, in the profdeep grades, they are *useless* warnings since there's
> nothing you can do about them.  (Presuambly, --warn-non-tail-recursion
> respects --halt-at-warn, which is going to be a problem in profdeep
> grades if the --halt-at-warn is also present in your Mercury.options
> file.)

Uses can:
    * Be aware that their programs may crash.
    * When they crash, more quickly decide to increase heap space or use
      stack segments.
    * Turn off deep profiling.

> >or running out of stack space.
> 
> That won't come as a surprise since I've read the user's guide
> and that's what it says will happen!

You and I are not a fair test of user-friendlyness.  We're too aware of how
Mercury and deep profiling works.

Another option is if deep profiling and --warn-non-tail-recursive are both
enabled, emit one general warning only.  The text of the warning message
could even change depending on the stseg grade component.

> >Does the answer to this change if we take away the historical
> >behaviour of breaking tail recursion in deep profiling grades?
> 
> How do you propose to do that?  We do have an undocumented option
> for allowing (some) tail recursion in deep profiling grades, however
> we currently say the following about it:
> 
>    % We do not currently enable (or publicly document) this option
>    % because its use results in significant overheads. Also, it is not
>    % compatible with coverage profiling, which is enabled by default. By
>    % default, all deep profiling grades are also built with
>    % --stack-segments in order to avoid problems caused by the lack of
>    % tail recursion.
> 
> (I suspect it's actually broken due to bitrot in any case.)

Yes, I think this is broken.

That's not what I meant anyway (sorry I didn't explain it clearly).  I'm not
proposing changing deep profiling.  I'm asking if the answer to this
question changes if we consider new users who aren't aware that deep
profiling breaks tail recursion.


-- 
Paul Bone