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

[Paul Bone]

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 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.

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.  This is more of an ideal
rather than a realistic goal (for Mercury in it's current status).


>>  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.


-- 
Paul Bone