[m-rev.] for post-commit review: semantic help pieces for grade options

[Zoltan Somogyi]

On Mon, 14 Jul 2025 14:25:12 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> >      --memory-profiling                  (grade modifier: `.memprof')
> >          Prepare the generated code for profiling of memory usage and
> retention
> > -        by mprof. This option is supported only when targeting C.
> > +        by mprof. Please see the
> > +        "Using mprof for profiling memory retention" section in the
> Mercury
> > +        User's Guide for details.
> 
> I don't think memory rentention profiling is the main thing that memprof
> grades
> are used for, so I would either say:
> 
>    Please see the "Using mprof for profiling memory allocation" and
>    "User mprof for profiling memory retention" sections in the Mercury
>    User's Guide for details.
> 
> or, if you have to list one only section, point to the allocation one.

I don't have any objection to this, but I would like to understand the
situation before I make any changes. I don't usually use mprof (I use
the deep profiler instead), and I don't usually even install the mprof-related
grades, so I am asking you guys: what happens if you invoke mprof -m
on a profile for a program that was compiled in a .prof (but not .memprof) grade?

Do you get the same info as you would get from a program compiled in
a .memprof grade? Less detailed but still useful info?
Or nothing useful at all?

And can mprof still do its usual call-counting and time-profiling tasks
for a program compiled in a .memprof grade? Is there *anything* that mprof
can do for a program compiled in .prof grade that it cannot do for .memprof grade?

As far as I can tell, the current user guide is silent on these questions.

Zoltan.