[m-users.] mmc option parallel
paul at bone.id.au
Mon Mar 16 10:23:28 AEDT 2015
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
> 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
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
> 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.
More information about the users