[m-rev.] For review: Compiler feedback system.

Julien Fischer juliensf at csse.unimelb.edu.au
Wed Jul 23 15:45:25 AEST 2008


> On Mon, Jul 21, 2008 at 01:57:43PM +1000, Julien Fischer wrote:
>>
>> On Sun, 20 Jul 2008, Paul Bone wrote:
>>
>>> Estimated hours taken: 8
>>> Branches: main
>>>
>>> Introduce a feedback system and modify Jerome's implicit parallelism work
>>> to
>>> use it.  Generic information can now be fed back into the compiler to aid
>>> with
>>> optimizations.
>>
>> Include a little more detail about the feedback system in the log
>> message.
>>
>> Separate out the first change from the second in the above, e.g.
>>
>>
>> 	Introduce a feedback system ...
>>
>> 	Modify the implicity parallelism ...
>>
>
> Done,  Now reads:
>
> Introduce a feedback system that allows analysis tools to feed information
> back into the compiler.  This can be used with the deep profiler to improve
> many optimizations.  Tools update information in the feedback file rather than
> clobbering existing un-related information.
>
> Modify the implicit parallelism work to make use of the new feedback system.
> mdprof_feedback updates a feedback file and in the future will be able to
> collect more information from the deep profiler.
>
>
>>> @@ -458,6 +477,53 @@ postprocess_options_2(OptionTable0, Targ
>>>        globals.lookup_bool_option(!.Globals,
>>>            automatic_intermodule_optimization, AutoIntermodOptimization),
>>>
>>> +        % Implicit parallelism requires feedback information.
>>> +        globals.lookup_bool_option(!.Globals, implicit_parallelism,
>>> +            ImplicitParallelism),
>>> +        (
>>> +            ImplicitParallelism = yes,
>>> +            globals.lookup_string_option(!.Globals, feedback_file,
>>> +                FeedbackFile),
>>> +            (
>>> +                FeedbackFile = ""
>>> +            ->
>>> +                add_error("'--implicit-parallelism' requires
>>> '--feedback'",
>>> +                    !Errors)
>>> +            ;
>>> +                true
>>> +            ),
>>> +            % TODO: should 'implicit_parallism' imply 'parallel'?
>>
>> No, --parallel is a component of the chosen grade.  If I only enable
>> --implicit-parallelism for individual modules (e.g. by listing them
>> separately in a Mercury.options file) then those modules might be
>> compiled in a different grade.
>>
>
> In that case should this produce an error when --implicit-parallelism is
> used in a non-parallel grade?

No.  The implicit parallelism pass should just not be run in such
grades.  Emitting an error would be a problem where you had

 	MCFLAGS = --implicit-parallelism

in a Mercury.options file but you also wanted to able to compile in
non-parallel grades, but use implicit parallelism in parallel grades.

> In this predicate I've found it hard to work out where things should be
> put that makes some kind of sense, I've put this change near the top but
> is there a better way to maintain the code in this predicate?
>
>>> +            globals.lookup_bool_option(!.Globals, parallel, Parallel),
>>> +            (
>>> +                Parallel = yes
>>> +            ;
>>> +                Parallel = no,
>>> +                add_error("'--implicit_parallelism' requires
>>> '--parallel'",
>>> +                    !Errors)
>>> +            ),
>>> +            globals.lookup_bool_option(!.Globals, highlevel_code,
>>> HighLevelCode),
>>> +            (
>>> +                HighLevelCode = yes,
>>> +                add_error("'--implicit-parallelism' is not compatible
>>> with "
>>> +                    ++ "'--highlevel-code'", !Errors)
>>> +            ;
>>> +                HighLevelCode = no
>>> +            ),
>>> +            (
>>> +                Target = target_c
>>> +            ;
>>> +                ( Target = target_il
>>> +                ; Target = target_java
>>> +                ; Target = target_asm
>>> +                ; Target = target_x86_64
>>> +                ; Target = target_erlang ),
>>> +                add_error("'--implicit-parallelism' is not compatible
>>> with "
>>> +                    ++ "target " ++ string(Target), !Errors)
>>> +            )
>>> +        ;
>>> +            ImplicitParallelism = no
>>> +        ),
>>> +
>>>        % Generating IL implies:
>>>        %   - gc_method `automatic' and no heap reclamation on failure
>>>        %     Because GC is handled automatically by the .NET CLR

For the same reason I don't think it is worth emitting the above errors.
Just don't run --implicit-parallelism if the grade will not support it.

The rest of the diff looks fine.
You can go ahead and commit it.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list