[m-dev.] New release?

[Paul Bone]

On Thu, Oct 22, 2015 at 01:45:11PM +1100, Zoltan Somogyi wrote:
> 
> On Wed, 21 Oct 2015 10:49:16 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > Actually, I was thinking about grade options earlier today, prompted by the same
> > concern. I think I will have a proposal worked out in a day or two.
> 
> My proposal is attached. At the moment, it is a description
> of an approach, with some details missing, because it makes sense
> to work out those details only if there is agreement on the basic
> approach. I intend this proposal to start a discussion on its approach.
> 
> If someone wants to turn the proposal into a wiki, go ahead.
> 

Thank you.  I like the general idea here and believe that it will be worth
while.  It represents a good compromise between the current power we have in
choosing so many build options, and making things simpler.  I also think
that, apart from some double maintenance and a related problem of "what
grades do I install?" it is the simplest (least effort to implement)
proposal that could be made given our current implementation.

For things like this, which are mostly of interest to developers, the
discussions repository is a better place for it than the wiki.  How it works
from the user's perspective is probably a good submission for the wiki.

In my first look at this I have the following suggestions:


> The idea is to let a user specify via an option that he/she would like
> to choose a specific value for a specific solver variable. The system would
> 
>  1  take the set of such choices expressed on the command line
>  2  if those choices are inconsistent, then
>  3      report an error for each source of inconsistency
>  4  else
>  5      for each so-far-unbound solver variable, in a chosen order:
>  6          compute the set of values of this solver variable that are
>  7              consistent with the values of the already-bound variables
>  8          if this set contains just one value
>  9              bind the variable to this value
> 10          else
> 11              bind the variable to the value in the set that
>                    the user is most likely to implicitly want
>                 (in the table below, the default is the most preferred value)

It looks like lines 8-9 are intended to implement a propagation step.  In
that case I would prefer to use a while loop (line 5), and propagate to
_any_ variable with a singleton set of "consistent values".

For example:

    take the set of such choices expressed on the command line
    if those choices are inconsistent, then
        report an error for each source of inconsistency
    else
 5      while there are unbound variables
            for each so-far unbound variable (any order):
                compute the set of values of this solver variable that are
                    consistent with the values of the already-bound variables
                if this set contains just one value
                    bind the variable to this value
                    break out of both loops (back to line 5)
            choose a variable (using "chosen order" as in Zoltan's line 5
            bind the variable to the value in the set that
               the user is most likely to implicitly want
            (in the table below, the default is the most preferred value)

This ensures that if the user specifies TAR=java, then CL=high will always
be set (via propagation) before a choice is made on a variable such as REG.
(REG=n will be propagated soon after.)


> --------------------------------------------------------
> 
> NOTE: This includes only the user-visible solver variables. There will be
> some non-user-visible ones as well, such as high tag vs low tag bits
> vs no tag bits, and --num-tag-bits.
> 
> XXXs means something is missing, and will need to be added.
> ??? marks a decision that I (zs) think should be reviewed.
> 
> solver variable CL:
>     CL.hlc: high level code
>     CL.llc: low level code          (requires TAR.c)
> 
> solver variable DL:
>     DL.hld: high level data         (requires CL.hlc)
>     DL.lld: low level data
>     (default is DL.lld)
>
> solver variable TAR:
>     TAR.c:  C
>     TAR.cs: C#                      (requires CL.hlc)
>     TAR.j:  Java                    (requires CL.hlc)
>     TAR.e:  Erlang                  (requires CL.hlc)
>     (default is TAR.c)

I think that "j" is the name of a language.  We may want to avoid confusion
and call this "java".

> solver variable NEST:
>     NEST.n: no gcc nested functions
>     NEST.y: gcc nested functions    (requires CL.hlc and TAR.c)
>     (default is NEST.n)
> 
> solver variable REG:
>     REG.n: no gcc global registers
>     REG.y: gcc global registers     (requires CL.llc and TAR.c)
>     (default is REG.y if supported on platform)
> 
> solver variable GOTO:
>     GOTO.n: no gcc nonlocal gotos
>     GOTO.y: gcc nonlocal gotos      (requires CL.llc and TAR.c)
>     (default is GOTO.y if supported on platform)
> 
> solver variable ASM:
>     ASM.n: no gcc asm labels
>     ASM.y: gcc asm labels           (requires CL.b and GOTO.y)
>     (default is ASM.y if supported on platform)

In your "chosen order" we may have to be careful with these variables, or
even choose the order dynamically or add backtracking.

If a user has not specified anything and a their platform supports REG but
not GOTO, and REG=y is selected first, then that would propagate CL=llc.
Unfortunately they'll end up with a grade like reg.gc when they could have
had a faster grade like hlc.gc.  This can probably be fixed by always
choosing CL before REG, GOTO or ASM.

> 
> solver variable SS:
>     SS.n: no stack segments
>     SS.y: stack segments            (requires CL.llc)
>     (default is SS.y ???)
>     XXX we should make MR_EXTEND_STACKS_WHEN_NEEDED undocumented
> 
> solver variable TSAFE:
>     TSAFE.n: no thread safe
>     TSAFE.y: thread safe
>     (default is TSAFE.n)
>
> solver variable GC:
>     GC.no:   no gc
>     GC.bdw:  boehm gc
>     GC.bdwd: boehm gc debug
>     GC.nat:  native gc              (requires CL.hlc and TAR.{java,erlang,XXX}
>     GC.acc:  accurate gc            (requires CL.hlc and TAR.c)
>     GC.rafe: becket history gc      (requires CL.hlc and XXX)
>     (default is GC.bdw)

While GC=nat requires TAR=java, erlang or C#.  I think it's more natural to
make this propagate the other way.  So TAR=java implies GC=nat.  (Both are
logically true, just from a user's perspective.)

> solver variable DEEP:
>     DEEP.n: no deep profiling
>     DEEP.y: deep profiling          (requires CL.llc and TIME.n and CALLS.n and MEM.n)
>     (default is DEEP.n)
> 
> solver variable TIME:
>     TIME.n: no gprof time profiling
>     TIME.y: gprof time profiling    (requires CL.llc and DEEP.n)
>     (default is TIME.n)
> 
> solver variable CALL:
>     CALL.n: no gprof call profiling
>     CALL.y: gprof call profiling    (requires CL.llc and DEEP.n and XXX)
>     (default is CALL.n)
> 
> solver variable MEM:
>     MEM.n: no gprof memory profiling
>     MEM.y: gprof memory profiling   (requires CL.llc and DEEP.n and XXX)
>     (default is MEM.n)
> 
> solver variable SCOPE:
>     SCOPE.n: no threadscope profiling
>     SCOPE.c: threadscope profiling  (requires XXX)
>     (default is SCOPE.n)

Requires TAR=c, CL=llc and TSAFE=y.  It should probably be relaxed to also
work with high level C.

It is very much unsupported at the moment.  The graphical threadscope tool
no-longer recognizes our profiles.  so supporting it without writing our own
viewer is useless.

> solver variable SIZE:
>     SIZE.n: no term size profiling
>     SIZE.c: term size profiling cells (requires CL.llc)
>     SIZE.w: term size profiling words (requires CL.llc)
>     (default is SIZE.n)
>
> solver variable TR:
>     TR.n: no trailing
>     TR.y: trailing                  (requires MM.n)
>     (default is TR.n)
> 
> solver variable MM:
>     MM.n:  no minimal model tabling
>     MM.c:  stack copy mm, no debug  (requires CL.llc and (GC.bdw or GC.bdwd) and TR.n)
>     MM.cd: stack copy mm, debug     (requires CL.llc and (GC.bdw or GC.bdwd) and TR.n) (not yet documented)
>     MM.o:  own stack mm, no debug   (requires CL.llc and (GC.bdw or GC.bdwd) and TR.n) (not yet documented)
>     MM.od: own stack mm, debug      (requires CL.llc and (GC.bdw or GC.bdwd) and TR.n) (not yet documented)
>     (default is MM.n)
> 
> solver variable SPF:
>     SPF.n: no single prec float
>     SPF.y: single prec float
>     (default is SPF.n)

Requires TAR=c?

> solver variable DBG:
>     DBG.n:  no debugging
>     DBG.d:  debugging               (requires CL.llc ???)
>     DBG.dd: declarative debugging   (requires CL.llc)
>     DBG.s:  ss debugging            (requires CL.hlc ???)
> 
> solver variable TSCOPE:
>     TSCOPE.n: no threadscope
>     TSCOPE.y: threadscope           (requires XXX)

You have this as SCOPE above.  TSCOPE is probably a better name.

I started work to rename this completely, after realising that support for
Mercury in the threadscope viewer would frequently be broken.


-- 
Paul Bone