[m-rev.] for post-commit review: fix mantis bug 361

[Julien Fischer]

Hi Paul,

On Thu, 18 Sep 2014, Paul Bone wrote:

> On Thu, Sep 18, 2014 at 02:27:59PM +1000, Julien Fischer wrote:
>>
>> On Thu, 18 Sep 2014, Paul Bone wrote:
>>
>>> Can we make debug imply decldebug and remove the explicit "decldebug" grade
>>> modifier?  To say it another way, if I want a debugging grade is it ever
>>> "bad" to add the declrative debugging features?
>>
>> To the best of my knowledge the is still some extra overhead involved
>> with the full decldebug grade, which is why they are still separate.
>>
>>> Similarly, I think that the par grade component on the low level C backend
>>> should always imply the stseg grade component.
>>
>> The unfortunate overloading of the par component to mean different
>> things for the high- and low-level C backends is already confusing
>> enough.  I don't want to make it more confusing by have par imply stseg
>> in some cases as well.
>
> I realize that by making one item imply another we can create confusion, but
> I hope to reduce confusion for programmers who just want "the best low-level
> C parallel configuration" or "the best high-level C parallel configuration".

The proposal further back in this thread was to add 'choose-the-best'
grade component options.  For the 'choose-the-best' --parallel option I
would have no objections to it preferring a .stseg.par grade over a .par
grade when targetting low-level C if both are available.

> The confusion between the different capabilities of the parallel grades (and
> grades/backends in general) is something we're already working on to fix,
> for example Peter's spawn_native contribution and your effort to standardize
> the behaviour of floating point to string conversion between the different
> grades.

The floating point stuff is primarily down to differences between the
target langauges and, for C, the fact that these things are not very
strongly defined in the first place.

> This is easier said than done but I think that the user shouldn'd have to
> think about grades at all.  Typically their choices come down to just a few
> options: Make it go fast, make debugging possible, or make profiling
> possible.  And nowdays: make parallelism possible.

That is precisely what Zoltan and I have said further back in this
thread; however IMO the --add-grade-component options and the grade
components themselves are not the right way to do this.

> This is more of an ideal rather than a realistic goal (for Mercury in
> it's current status).

I think it's perfectly reasonable to (eventually) allow things like:

    $ mmc --debug foo.m

(Compile the program in the best available grade that can be used for
debugging.)

    $ mmc --debug --trailing foo.m

(Compile the program in the best available grade that supports both
debugging and trailing.)

For the 'choose-the-best' options I think we need to make a distinction
between --parallel and --multithreaded, for example:

    $ mmc --high-level-code --parallel foo.m

should be an error since the hlc grades don't support parallel
conjunction.  The feature set pragmas already make this distinction
between parallelism and concurrency.

>>>  And AFAIK it's rare that someone would want the stseg feature in a
>>>  non-parallel build.
>>
>> The configure script currently enables stack segments by default for
>> every for every low-level C grade except {asm_fast,reg,none}.gc and
>> {asm_fast,reg,none}.gc.trseg, so it's hardly something that is
>> restricted to the par grade.  (I am in favour of enabling stack segments
>> by default for every low-level C grade.)
>
> I don't remember what the impact is but I don't think it's particularly
> large so I'd be in favor of enabling it everywhere as well.

That's odd, because IIRC you were the person who objected the last time
I suggested it.

Cheers,
Julien.