[m-users.] mmc option parallel

[Paul Bone]

On Sun, Mar 15, 2015 at 07:38:31PM +0100, Matthias Güdemann wrote:
> Hi all,
> 
> when I use the option '--parallel' for mmc, but did not explicitely
> specify a parallel grade, the compilation fails with:
> 
> mercury_compile: error: the Mercury standard library cannot be found in grade asm_fast.par.gc.
> 
> This is unsuprising, as this grade is not installed (does is even
> exist?)
> 
> I fixed this locally by adding
> 
>     % The pthreads headers on some architectures (Solaris, Linux)
>     % don't work with -ansi.
>     option_implies(parallel, ansi_c, bool(no), !Globals),
> ->  option_implies(parallel, stack_segments, bool(yes), !Globals), <-
> 
> in handle_options.m for the convert_options_to_globals predicate. This
> change seems to work with 14.01.1.
> 
> Yet, I am fully aware that this is the *wrong solution*. It adds 'stseg'
> to any parallel grade, even for hlc.par, where is does not make any
> sense.

Hi Matthias,

The underlying problem here is that there's not much separation between the
--parallel option and the .par grade component.  They are pretty much
one-and-the-same.  For now the best workaround is either to specify
--stack-segments directly or specify the full grade and not the grade
options.

> I still think that selecting a valid parallel grade for asm_fast would
> be a better idea than failing on compilation when specifying the
> 'parallel' option without explicit parallel grade. IIRC, I never had a
> low-level parallel grade without '.stseg', therefore I propose adding
> the 'stack_segments' option to parallel, low-level C target.

I believe that the long term solution is to make a clear separation between
options and grade components.  And possibly to abstract away grades
altogether.  A user should be able to say "I want parallelism" and get it,
as you suggest, by the system choosing the best parallel grade available.

Thanks.


-- 
Paul Bone