[m-dev.] Re: diff: handling of --grade options
Tyson Richard DOWD
trd at students.cs.mu.oz.au
Wed Oct 8 14:33:44 AEST 1997
Fergus Henderson wrote:
> Hi,
>
> Anyone want to review this change?
Ok, I'm game.
>
> compiler/options.m:
> compiler/handle_options.m:
> compiler/mercury_compile.m:
> scripts/mgnuc.in:
> scripts/ml.in:
>
> Change mgnuc and ml to support the same
> compilation model options as mmc.
> Allow the user to mix `--grade foo' options with
> other options that affect the grade such as `--profiling'.
> Compute the final grade to link with from the options.
>
> Add `--profile-time' and `--profile-calls' options.
> Change `--profiling' to now just imply both of those.
> Add support for grades *.proftime and *.profcalls.
>
> Add `--pic-reg' option (just implies `-DPIC_REG' in cflags).
>
> Make `.debug' a grade modifier, rather than having a base
> grade `debug'.
>
> doc/user_guide.texi:
> README.Linux:
> Document the above changes.
>
> +/*
> +% These vary from machine to machine, and (for backwards compatibility,
> +% if nothing else) we want examples such as "GRADE = asm_fast.gc.prof"
> +% to continue to work, so we can't include these in the grade.
> + globals__get_tags_method(Globals, TagsMethod),
> + globals__lookup_int_option(Globals, tag_bits, TagBits),
> + globals__lookup_bool_option(Globals, unboxed_float, UnboxedFloat),
> +*/
When is the commented out code (here and elsewhere) intended to be used?
I assume there is going to be a time lag for compatibility.
> convert_grade_option(Grade0) -->
> - ( { string__remove_suffix(Grade0, ".tr", Grade1) } ->
> + % part10
> + ( { string__remove_suffix(Grade0, ".picreg", Grade1) } ->
> { Grade2 = Grade1 },
> - set_bool_opt(use_trail, yes)
> + set_bool_opt(pic_reg, yes)
> ;
> { Grade2 = Grade0 },
> - set_bool_opt(use_trail, no)
> + set_bool_opt(pic_reg, no)
> ),
> - ( { string__remove_suffix(Grade2, ".prof", Grade3) } ->
> + % part9
> + ( { string__remove_suffix(Grade2, ".debug", Grade3) } ->
> { Grade4 = Grade3 },
> - set_bool_opt(profiling, yes)
> + set_bool_opt(debug, yes)
> ;
> { Grade4 = Grade2 },
> - set_bool_opt(profiling, no)
> + set_bool_opt(debug, no)
> + ),
> + % part8
> + ( { string__remove_suffix(Grade4, ".sa", Grade5) } ->
> + { Grade6 = Grade5 },
> + set_string_opt(args, "simple")
> + ;
> + { Grade6 = Grade4 },
> + set_string_opt(args, "compact")
> + ),
> + % part6 & 7
> + { Grade10 = Grade6 },
> + % part5
> + ( { string__remove_suffix(Grade10, ".tr", Grade11) } ->
> + { Grade12 = Grade11 },
> + set_bool_opt(use_trail, yes)
> + ;
> + { Grade12 = Grade10 },
> + set_bool_opt(use_trail, no)
> ),
> - ( { string__remove_suffix(Grade4, ".gc", Grade5) } ->
> - { Grade = Grade5 },
> + % part 4
> + ( { string__remove_suffix(Grade12, ".prof", Grade13) } ->
> + { Grade14 = Grade13 },
> + set_bool_opt(profile_time, yes),
> + set_bool_opt(profile_calls, yes)
> + ; { string__remove_suffix(Grade12, ".proftime", Grade13) } ->
> + { Grade14 = Grade13 },
> + set_bool_opt(profile_time, yes),
> + set_bool_opt(profile_calls, no)
> + ; { string__remove_suffix(Grade12, ".profcalls", Grade13) } ->
> + { Grade14 = Grade13 },
> + set_bool_opt(profile_time, no),
> + set_bool_opt(profile_calls, yes)
> + ;
> + { Grade14 = Grade12 },
> + set_bool_opt(profile_time, no),
> + set_bool_opt(profile_calls, no)
> + ),
> + % part 3
> + ( { string__remove_suffix(Grade14, ".gc", Grade15) } ->
> + { Grade = Grade15 },
> { GC = conservative }
> - ; { string__remove_suffix(Grade4, ".agc", Grade5) } ->
> - { Grade = Grade5 },
> + ; { string__remove_suffix(Grade14, ".agc", Grade15) } ->
> + { Grade = Grade15 },
> { GC = accurate }
> ;
> - { Grade = Grade4 },
> + { Grade = Grade14 },
> { GC = none }
> ),
> % Set the type of gc that the grade option implies.
> @@ -344,6 +495,7 @@
> { GC = none },
> set_string_opt(gc, "none")
> ),
> + % parts 2 & 1
> convert_grade_option_2(Grade).
If this gets any longer, I'd recommend redesigning it to use some
sort of table -- almost all the code is duplicate code, and even
the exceptions aren't very different. As it is, it's pretty ugly.
(Leaving room for Grade6 -- Grade10 at least that avoids the immediate
problem of maintainability).
Index: doc/user_guide.texi
> ===================================================================
> RCS file: /home/staff/zs/imp/mercury/doc/user_guide.texi,v
> retrieving revision 1.98
> diff -u -r1.98 user_guide.texi
> --- user_guide.texi 1997/10/03 04:56:13 1.98
> +++ user_guide.texi 1997/10/07 19:51:54
> @@ -914,8 +914,7 @@
>
> Due to a known timing-related bug in our code, you may occasionally get
> segmentation violations when running your program with profiling enabled.
> -If this happens, just run it again --- the problem does not occur frequently.
> -This bug will hopefully be fixed soon.
> +If this happens, just run it again --- the problem occurs very rarely.
What sort of profiling (time or call) triggers this problem?
> + at samp{none}, @samp{reg}, @samp{jump}, @samp{asm_jump},
> @samp{fast}, @samp{asm_fast},
> -or one of those with @samp{.gc}, @samp{.prof} or @samp{.gc.prof} appended.
> +or one of those with @samp{.gc}, @samp{.prof}, and/or @samp{.tr} appended.
Isn't order important for this?
> + at sp 1
> + at item @code{--profile-time} (grades: any grade containing @samp{.proftime})
> +Similar to @samp{--profiling}, except that this option only gathers
> +timing information, not call counts. For the results to be useful,
> +call counts for an identical run of your program need to be gathered
> +using @samp{--profiling} or @samp{--profile-calls}.
> +The only advantage of using @code{--profile-time} is that it can give
The only advantage of using --profile-time *alone* is that....
Also, there's a lot of shared code in ml.in and mgnuc.in.
Any way to use only one copy of it?
Otherwise, the diff looks ok, but it probably needs a lot of testing to be
more certain. (I'm not well enough to concentrate on checking all these
thousands of options...).
--
Tyson Dowd # Another great idea from the
# people who brought you
trd at .cs.mu.oz.au # Beer Milkshakes!
http://www.cs.mu.oz.au/~trd # Confidence --- Red Dwarf
More information about the developers
mailing list