Commit Graph

71 Commits

Author SHA1 Message Date
Zoltan Somogyi
b6178ef723 Delete prog_out.m, moving its code to other modules.
compiler/parse_tree_out_cons_id.m:
    Move the predicates and functions in prog_out.m that deal with cons_ids
    to this module.

compiler/parse_tree_out_sym_name.m:
    Move the predicates and functions in prog_out.m that deal with sym_names
    and similar entities to this module.

compiler/parse_tree_out_type.m:
    Move the predicates and functions in prog_out.m that deal with types
    to this module.

compiler/parse_tree_out_misc.m:
    Move the predicates and functions in prog_out.m that deal with simple
    types to this module.

    Delete mercury_output_det and mercury_format_det, replacing all their
    uses with calls to mercury_det_to_string.

compiler/prog_out.m:
    Delete this module.

compiler/parse_tree.m:
    Delete prog_out from the parse_tree package.

compiler/Mercury.options:
compiler/notes/compiler_design.html:
    Delete references to prog_out.m.

compiler/*.m:
    Update imports and any explicit module qualifications to account
    for the moved code.

tools/filter_sort_imports:
    Automatically filter out any repeated imports. This can help with
    changes like this that redistribute the contents of one module to other
    modules. In this case, after a global replacement of prog_out's import
    with the import of parse_tree_out_misc, this updated script could
    remove this changed import from modules that already imported
    parse_tree_out_misc.
2023-04-09 16:23:13 +10:00
Julien Fischer
383ab55e75 Fix spelling and doubled-up words.
compiler/globals.m:
compiler/hlds_goal.m:
compiler/ml_global_data.m:
compiler/modes.m:
compiler/prog_data_pragma.m:
compiler/structure_reuse.analysis.m:
    As above.
2021-06-14 20:15:52 +10:00
Zoltan Somogyi
40725f170e Replace ten int cons_ids with one.
We currently have one function symbol in the cons_id type for each
of our ten types of integer constants: signed vs unsigned, and
word-sized, 8-bit, 16-bit, 32-bit and 64-bit. In most places in the compiler,
these are all treated the same, and it gets tedious to have to write
the same logic ten times. This diff therefore changes things so that
the distinction between int constants of these ten types is pushed
to one level lower than the cons_id type.

compiler/prog_data.m:
    Replace the ten cons_ids {int,uint}{,8,16,32,64}_const with just one,
    some_int_const, whose argument now has those function symbols.

    Add some utility functions on integer constants.

compiler/prog_out.m:
    Add a utility predicate for converting int constants to strings.

compiler/parse_tree_to_term.m:
    Add a utility predicate for converting int constants to terms.

compiler/old_type_constraints.m:
    Conform to the changes above.

    Fix an old bug, though this does not matter since this module is unused.

compiler/add_pred.m:
compiler/bytecode_gen.m:
compiler/const_prop.m:
compiler/coverage_profiling.m:
compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/deep_profiling.m:
compiler/dep_par_conj.m:
compiler/distance_granularity.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_dependency_graph.m:
compiler/hlds_out_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/intermod.m:
compiler/make_goal.m:
compiler/mercury_to_mercury.m:
compiler/ml_global_data.m:
compiler/mode_util.m:
compiler/modecheck_coerce.m:
compiler/modecheck_goal.m:
compiler/module_qual.qualify_items.m:
compiler/parse_util.m:
compiler/polymorphism.m:
compiler/polymorphism_type_info.m:
compiler/prog_ctgc.m:
compiler/prog_rep.m:
compiler/prog_type.m:
compiler/prog_util.m:
compiler/rbmm.execution_path.m:
compiler/rbmm.region_transformation.m:
compiler/simplify_goal_call.m:
compiler/structure_reuse.direct.choose_reuse.m:
compiler/superhomogeneous.m:
compiler/typecheck.m:
compiler/typecheck_errors.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
    Conform to the changes above. Use the new utility predicates
    to avoid code duplication.
2021-06-03 23:58:32 +10:00
Zoltan Somogyi
e512472122 Try to delete duplicate rows in MLDS scalar commons.
compiler/mlds_to_c_type.m:
    Provide a way to replace types in MLDS initializers with a
    "more standard" type.

compiler/ml_global_data.m:
    When targeting C, add code to use the new function in mlds_to_c_type.m
    to attempt to detect when two initializers will generate the same code
    even if their original MLDS forms differ. This is so that we can use
    the same row in a scalar common structure, instead of the two mapping
    to separate rows with identical contents.

    Comment out the new code, because the benefit is too small to be worth
    the cost in compiler execution time.
2021-05-18 11:39:59 +10:00
Zoltan Somogyi
d273494121 Rename a functor to avoid ambiguity. 2021-05-17 18:52:24 +10:00
Zoltan Somogyi
ba59f6313c Make unsigned_lt a builtin operation, step 1.
Step 1 is making it a builtin; step 2 will be declaring it.
(We won't define it, since builtins may not have definitions.)

compiler/builtin_ops.m:
    Make unsigned_lt a builtin operation, and recognize
    private_builtin.unsigned_lt which does not exist yet,
    as that operation.

    We already had a builtin operation unsigned_le, which the compiler
    generated references to internally. Recognize private_builtin.unsigned_le
    as this builtin operation. The difference is that just having a builtin op
    is enough for compiler passes inside the LLDS/MLDS/ELDS backends
    that generate LLDS/MLDS/ELDS code that refer to the builtin op,
    (though the ELDS backend does not have any code that does such things),
    while code that wants to create references to builtin ops in the HLDS
    needs to have access to the predicate declaration of each builtin.
    So far, we intend to use only unsigned_lt, not unsigned_le, in this manner,
    but treating two such closely related ops differently would violate
    the law of least astonishment.

    Fix an old XXX that is related to this diff only in affecting the same
    type: standardize on add/sub/mil/div terminology over
    plus/minus/times/divide terminology.

compiler/erl_call_gen.m:
    Abort on references to unsigned_lt as well as unsigned_le.

compiler/llds_out_data.m:
compiler/ml_global_data.m:
compiler/mlds_to_c_data.m:
    The C backends already implemented unsigned_le. Handle unsigned_lt
    the same way as unsigned_le, only with s/<=/</.

compiler/mlds_to_cs_data.m:
    Implement both unsigned_lt and unsigned_le, using the C# foreign_proc
    implementation of unsigned_lt in library/int.m as a basis.

compiler/mlds_to_java_data.m:
    Implement both unsigned_lt and unsigned_le, using the Java foreign_proc
    implementation of unsigned_lt in library/int.m as a basis.

compiler/options.m:
    Provide a way to detect whether the installed compiler has this diff.
    We will need such a test in configure.ac for stage 2.

compiler/bytecode.m:
compiler/llds.m:
compiler/mlds_dump.m:
compiler/opt_debug.m:
    Conform to the changes above.

library/int.m:
    Module qualify references to unsigned_lt. This is to allow the
    affected code to compile even after the declaration of unsigned_lt
    as a predicate in private_builtin.m. (The last step of this sequence
    would be the deletion of both int.unsigned_lt and the references to it.)
2020-05-02 20:07:46 +10:00
Zoltan Somogyi
13e6050f16 Step one of adding unchecked shifts by uint amounts.
compiler/builtin_ops.m:
    Parameterize the unchecked left and right shift builtin ops
    by whether the shift amount is an int or an uint. So far,
    the shift amount has always been an int; allowing the shift amount
    to be a uint is new.

    Recognize the Mercury functions unchecked_{left,right}_ushift
    as being builtins implemented by the new variants of the unchecked
    shift builtin ops mentioned above. These Mercury functions do not
    exist yet. They will be added in step two of this diff, *after* this
    change has been installed. (Making something a builtin, and *then*
    defining it, is easier than defining it, and *then* making it a builtin,
    because in the latter case, the stage 1 and stage 2 compilers disagree
    on whether the function in question needs to have a definition.)

compiler/options.m:
    Provide a way to check whether an installed compiler has this diff.
    (This is needed for step 2.)

compiler/lookup_switch.m:
compiler/ml_lookup_switch.m:
compiler/ml_unify_gen_util.m:
compiler/unify_gen_util.m:
    When generating references to unchecked shift ops, specify that the
    shift amount is an int.

compiler/erl_call_gen.m:
    Don't treat unchecked shifts by uint amounts as builtins, since I (zs)
    don't know how this should be done in Erlang.

compiler/llds_out_data.m:
compiler/mlds_to_c_data.m:
compiler/mlds_to_cs_data.m:
    When writing out unchecked shifts for C or C#, cast the shift amount
    to int if it was originally uint.

compiler/mlds_to_java_data.m:
    When writing out unchecked shifts for Java, ignore the type of the
    shift amount, since (in the absence of a uint type in Java) we
    represent both int and uint values the same way.

compiler/bytecode.m:
compiler/c_util.m:
compiler/llds.m:
compiler/ml_global_data.m:
compiler/mlds_dump.m:
compiler/opt_debug.m:
    Conform to the changes above.
2020-04-30 17:16:30 +10:00
Zoltan Somogyi
b6d4d3f30d Fix more issues reported by --warn-inconsistent-pred-order-clauses. 2019-08-24 07:53:41 +10:00
Zoltan Somogyi
b66f45e4db Tighten the mlds_type type.
compiler/mlds.m:
    Make two changes to mlds_type.

    The simpler change is the deletion of the maybe(foreign_type_assertions)
    field from the MLDS representations of Mercury types. It was never used,
    because Mercury types that are defined in a foreign language that is
    acceptable for the current MLDS target platform are represented
    as mlds_foreign_type, not as mercury_type.

    The more involved change is to change the representation of builtin types.
    Until now, we had separate function symbols in mlds_type to represent
    ints, uints, floats and chars, but not strings or values of the sized
    types {int,uint}{8,16,32,64}; those had to be represented as Mercury types.
    This is an unnecessary inconsistency. It also had two allowed
    representations for ints, uints, floats and chars, which meant that
    some of the code handling those conceptual types had to be duplicated
    to handle both representations.

    This diff provides mlds_builtin_type_{int(_),float,string,char} function
    symbols to represent every builtin type, and changes mercury_type
    to mercury_nb_type to make clear that it is NOT to be used for builtins
    (the nb is short for "not builtin").

compiler/ml_code_util.m:
compiler/ml_util.m:
    Delete functions that used to construct MLDS representations of builtin
    types. The new representation of those types is so simple that using
    such functions is no less cumbersome than writing down the representations
    directly.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_proc_gen.m:
compiler/ml_rename_classes.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tag_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen_construct.m:
compiler/ml_unify_gen_deconstruct.m:
compiler/ml_unify_gen_util.m:
compiler/mlds_dump.m:
compiler/mlds_to_c_data.m:
compiler/mlds_to_c_export.m:
compiler/mlds_to_c_func.m:
compiler/mlds_to_c_global.m:
compiler/mlds_to_c_stmt.m:
compiler/mlds_to_c_type.m:
compiler/mlds_to_cs_data.m:
compiler/mlds_to_cs_stmt.m:
compiler/mlds_to_cs_type.m:
compiler/mlds_to_java_data.m:
compiler/mlds_to_java_stmt.m:
compiler/mlds_to_java_type.m:
compiler/mlds_to_java_wrap.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above.
2018-09-28 23:07:23 +10:00
Zoltan Somogyi
b9afc8b78e Delete the mlds_unary_op type.
compiler/mlds.m:
    We used to have a function symbol ml_unop in the mlds_rval type
    that applied one of four kinds of operations to an argument mlds_rval:
    boxing, unboxing, casting or a standard unary operation, with a value
    of type mlds_unary_op selecting between the four. Replace this system
    with four separate function symbols in the mlds_rval type directly,
    and delete the mlds_unary_op type.

    The new arrangement requires fewer memory cells to be allocated,
    and less indirection; it also leads to shorter and somewhat
    more readable code.

compiler/ml_optimize.m:
    Conform to the change above.

    Recognize that a cast has negligible cost.

compiler/ml_code_util.m:
    Conform to the change above.

    Keep private a predicate that is not used by any other module,
    after merging it with another previously-exported predicate
    that only *it* uses.

    Delete some other predicates that are not used anywhere.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_rename_classes.m:
compiler/ml_string_switch.m:
compiler/ml_tag_switch.m:
compiler/ml_unify_gen.m:
compiler/ml_unused_assign.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
    Conform to the change above.
2018-05-13 12:23:38 +02:00
Zoltan Somogyi
fc903a0911 Eliminate the double storage of types in the MLDS.
compiler/mlds.m:
    When we record a Mercury type in the MLDS, we used to record with it
    not just its type category (which some aux predicates need), but also
    the name by which it is known to the target language compiler, if the
    type is defined in that foreign language. Unfortunaly, the data structure
    we used to represent the name of the foreign type (and any assertions
    on it) also stored a duplicate copy of the Mercury type in the usual
    case where the Mercury type was *not* defined in the foreign language.
    Having two copies of the same information was dangerous, due to the
    possibility of inconsistency between them. It was also unnecessary work
    for the compiler passes that had to create the duplicate copies.

    Eliminate these problems by always storing *one* copy of the Mercury type.

    Store the Mercury and foreign type information next to each other.

compiler/foreign.m:
    Make the above possible by deleting up the old exported_type type,
    which contained the duplicate copy of the Mercury type in usual case
    of a type that is not defined by foreign code, and replacing it
    with a type that contains information about just a foreign type.

    In the argument lists of the predicates and functions of this module,
    replace arguments that used to be type exported_type with a pair
    of the Mercury type and a maybe of the new type, which is yes(...)
    iff the Mercury type *is* defined in foreign code.

    Give some predicates and functions more meaningful names.

    Make specialized versions of these functions available (specialized
    e.g. to a target language) where these would be useful.

    Delete the auxiliary predicates that aren't needed with the
    new data structure design.

compiler/export.m:
compiler/ml_accurate_gc.m:
compiler/ml_code_util.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_simplify_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above.
2018-05-08 00:17:34 +02:00
Zoltan Somogyi
24b98fdafe Pack sub-word-sized ints and dummies in terms.
Previously, the only situation in which we could pack two or more arguments
of a term into a single word was when all those arguments are enums. This diff
changes that, so that the arguments can also be sub-word-sized integers
(signed or unsigned), or values of dummy types (which occupy zero bits).

This diff also records, for each argument of a function symbol, not just
whether, and if yes, how it is packed into a word, but also at *what offset*
that word is in the term's heap cell. It is more economical to compute this
once, when the representation of the type is being decided, than to compute
it over and over again when terms with that function symbol are being
constructed or deconstructed. However, for a transition period, we compute
these offsets at *both* times, to check the consistency of the new algorithm
for computing offsets that is run at "decide representation time" with
the old algorithms run at "generate code for a unification time".

compiler/du_type_layout.m:
    Make the changes described above: pack sub-word-sized integers and
    dummy values into argument words, if possible, and if the relevant
    new option allows it. These options are temporary. If we find no problems
    with the new packing algorithm in a few weeks, we should be able to
    delete them.

    Allow 64 bit ints and uints to be stored in unboxed in two words
    on 32 bit platforms, if the relevant new option allows it. Support
    for this is not yet complete, but it makes sense to implement the
    RTTI changes for both this change and one described in the above
    paragraph together.

    For each packed argument, record not just its width, its shift and
    the mask, but also the number of bits the argument takes. Previously,
    we computed this on demand from the mask, but there is no real need
    for that when simply storing this info is so cheap.

    For all arguments, packed or not, record its offset, relative to both
    the start of the arguments, and the start of the memory cell. (The two
    are different if the arguments are preceded by either a remote secondary
    tag, the typeinfos and/or typeclass_infos describing some existentially
    typed arguments, or both.) The reason for this is given at the top.

    Centralize the decision of the parameters of packing in one predicate.

    If the option --inform-suboptimal-packing is given, print an informational
    message whenever the code deciding type representations finds that
    reordering the arguments of a function symbol would allow it to pack
    the arguments of that function symbol into less space.

compiler/options.m:
    Add the option --allow-packing-ints which controls whether
    du_type_layout.m will attempt to pack {int,uint}{8,16,32} arguments
    alongside enum arguments.

    Add the option --allow-packing-dummies which controls whether
    du_type_layout.m will optimize away (in other words, represent in 0 bits)
    arguments of dummy types.

    Add the option --allow-double-word-ints which controls whether
    du_type_layout.m will store arguments of the types int64 and uint64
    unboxed in two words on 32 bit platforms, the way it currently stores
    double precision floats.

    All three those options are off by default, which preserves binary
    compatibility with existing code. However, the first two are ready
    to be switched on (the third is not).

    All three options are intended to be present in the compiler
    only until these changes are tested. Once we deem them sufficiently
    tested, I will modify the compiler to always do the packing they control,
    at which point we can delete these options. This is why they are not
    documented.

    Add the option --inform-suboptimal-packing, whose meaning is described
    above.

doc/user_guide.texi:
    Document --inform-suboptimal-packing.

compiler/prog_data.m:
    For each argument of a function symbol in a type definition, use
    a new type called arg_pos_width to record the extra information
    mentioned above in (offsets for all arguments, and number of bits
    for packed arguments).

    For each function symbol that has some existential type constraints,
    record the extra information mentioned for parse_type_defn.m below.

compiler/hlds_data.m:
    Include the position, as well as the width, in the representation
    of the arguments of function symbols.

    Previously, we used the integer 0 as a tag for dummies. Add a tag to
    represent dummy values, since this gives more information to any code
    that sees that tag.

compiler/ml_unify_gen.m:
compiler/unify_gen.m:
    Handle the packing of dummy values, and of sub-word-sized ints and uints.

    Compare the cell offset of each argument computed using existing
    algorithms here with the cell offset recorded in the argument's
    representation, and abort if they are different.

    In some cases, restructure code a bit to make it possible.
    For example, for tuples and closures, this means that instead of
    simply recording that each tuple argument or closure element
    is a full word, we must record its correct offset as well.

    Handle the new dummy_tag.

    Add prelim (not yet finished) support for double-word int64s/uint64s
    on 32 bit platforms.

    When packing the values of two or more variables (or constants) into a
    single word in a memory cell, optimize away operations that are no-ops,
    such as shifting anything by zero bits, shifting the constant zero
    by any number of bits, and ORing anything with zero. This makes the
    generated code easier to read. It is probably also faster for us
    to do it here than to write out a bigger expression, have the C compiler
    read in the bigger expression, and then later make the same optimization.

    In ml_unify_gen.m, avoid the unnecessary use of a list of the argument
    variables' types separate from the list of the argument variables
    themselves; just look up the type of each argument variable when it is
    processed.

compiler/add_special_pred.m:
    When creating special (unify and compare) predicates for tuples,
    include the offsets in the representation of their arguments.

    Delete an unused predicate.

compiler/llds.m:
    Add a new way to create an rval: a cast. We use it to implement
    the extraction of signed sub-word-sized integers from packed argument
    words in terms. Masking the right N bits out of the packed word
    leaves the other 32-N or 64-N bits as zeroes; a cast to int8_t,
    int16_t or int32_t will copy the sign bit to these bits.
    Likewise, when we pack signed int{8,16,32} values into words,
    we cast them to their unsigned versions to throw away any sign-extension
    bits in their original word-sized representations.

    No similar change is needed for the MLDS, since that already had
    a mechanism for casts.

compiler/mlds.m:
    Note a potential simplification in the MLDS.

compiler/builtin_lib_types.m:
    Add functions to return the Mercury representation of the int64
    and uint64 types.

compiler/foreign.m:
    Export a specialized version of an existing predicate, to allow
    ml_unify_gen.m to avoid the costs of the more general version.

compiler/hlds_out_module.m:
    Always print the representations of all arguments, since the
    inclusion of position information in those representation means that
    the representations of even all-full-word-argument terms are of potential
    interest when debugging term representations.

compiler/lco.m:
    Do not try to apply LCO to arguments of dummy types. (We could optimize
    them differently, by filling them in before they are "computed", but
    that is a separate optimization, which is of *very* low priority.)

compiler/liveness.m:
    Do not include variables of dummy types in resume points.

    The reason for this is that the code that establishes a resume point
    returns, for each such variable, a list of *lvals* where that variable
    can be found. The new code in unify_gen.m will optimize away assignments
    to values of dummy types, so there is *no* lval where they can be found.
    We could allocate one, but doing so would be a pessimization. Instead,
    we simply don't save and restore such values. When their value (which is
    always 0) is needed, we can create them out of thin air.

compiler/ml_global_data.m:
    Include the target language in the ml_global_data structure, to prevent
    some of its users having to look it up in the module_info.

    Add notes about the specializing the implementation of arrays of
    int64s/uint64s on 32 bit platforms.

compiler/check_typeclass.m:
compiler/ml_type_gen.m:
    Add sanity checks of the new precomputed fields of exist_constraints.

    Conform to the changes above.

compiler/mlds_to_c.m:
    Add prelim (not yet finished) support for double-word int64s/uint64s
    on 32 bit platforms.

    Add notes about possible optimizations.

compiler/parse_type_defn.m:
    When a function symbol in a type definition contains existential
    arguments, precompute and store the set of constrained and unconstrained
    type variables. The code in du_type_layout.m needs this information
    to compute the number of slots occupied by typeinfos and typeclass_infos
    in memory cells for this function symbol, and several other places
    in the compiler do too. It is easier and faster to compute this
    information just once, and this is the earliest time what that can be done.

compiler/type_ctor_info.m:
    Use the prerecorded information about existential types to simplify
    the code here

compiler/polymorphism.m:
    Add an XXX about possibly using the extra info we now record in
    exist_constraints to simplify the job of polymorphism.m.

compiler/pragma_c_gen.m:
compiler/var_locn.m:
    Create the values of dummy variables from scratch, if needed.

compiler/rtti.m:
    Replace a bool with a bespoke type.

compiler/rtti_out.m:
compiler/rtti_to_mlds.m:
    When generating RTTI information for the LLDS and MLDS backends
    respectively, record new kinds of arguments as needing special
    treatment. These are int64s and uint64s stored unboxed in two words
    on 32 bit platforms, {int,uint}{8,16,32} values packed into words,
    and dummy arguments. Each of these has a special code: its own negative
    negative value in the num_bits field of the argument.

    Generate slightly better formatted output.

compiler/type_util.m:
    Delete a predicate that isn't needed anymore.

compiler/opt_util.m:
    Delete a function that hasn't been needed for a while.

    Conform to the changes above.

compiler/arg_pack.m:
compiler/bytecode_gen.m:
compiler/call_gen.m:
compiler/code_util.m:
compiler/ctgc.selector.m:
compiler/dupelim.m:
compiler/dupproc.m:
compiler/equiv_type.m:
compiler/equiv_type_hlds.m:
compiler/erl_code_gen.m:
compiler/erl_rtti.m:
compiler/export.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/livemap.m:
compiler/llds_out_data.m:
compiler/middle_rec.m:
compiler/ml_closure_gen.m:
compiler/ml_switch_gen.m:
compiler/ml_top_gen.m:
compiler/module_qual.qualify_items.m:
compiler/opt_debug.m:
compiler/parse_tree_out.m:
compiler/peephole.m:
compiler/recompilation.usage.m:
compiler/resolve_unify_functor.m:
compiler/stack_layout.m:
compiler/structure_reuse.direct.choose_reuse.m:
compiler/switch_util.m:
compiler/typecheck.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
    Conform to the changes above.

compiler/llds_out_util.m:
    Add a comment.

compiler/ml_code_util.m:
    Factor out some common code.

runtime/mercury_type_info.h:
    Allocate special values of the MR_arg_bits field of the MR_DuArgLocn type
    to designate arguments as two word int64/uint64s, as sub-word-sized
    arguments of types {int,uint}{8,16,32}, or as arguments of dummy types.
    (We already had a special value for two word float arguments.)

    Document the list of places that know about this code, so that they
    can be updated if and when it changes.

library/construct.m:
    Handle the construction of terms with two-word int64/uint64 arguments,
    with packed {int,uint}{8,16,32} arguments, and with dummy arguments.

    Factor out the code common to the sectag-present and sectag-absent cases,
    to make it possible to do the above in just *one* place.

library/store.m:
    Add an XXX to a place that I don't think handles two word arguments
    correctly. (I think this is an old bug.)

runtime/mercury_deconstruct.c:
    Handle the deconstruction of terms with two-word int64/uint64 arguments,
    with packed {int,uint}{8,16,32} arguments, and with dummy arguments.

runtime/mercury_deep_copy_body.h:
    Handle the copying of terms with two-word int64/uint64 arguments,
    with packed {int,uint}{8,16,32} arguments, and with dummy arguments.

    Give a macro a more descriptive name.

runtime/mercury_type_info.c:
    Handle taking the size of terms with two-word int64/uint64 arguments,
    with packed {int,uint}{8,16,32} arguments, and with dummy arguments.

runtime/mercury.h:
    Put related definitions next to each other.

runtime/mercury_deconstruct.h:
runtime/mercury_ml_expand_body.h:
    Fix indentation.

tests/hard_coded/construct_test.{m,exp}:
    Add to this test case a test of the construction, via the library's
    construct.m module, of terms containing packed sub-word-sized integers,
    and packed dummies.

tests/hard_coded/deconstruct_arg.{m,exp}:
    Convert the source code of this test case to state variable notation,
    and update the line number references (in the names of predicates created
    from lambda expressions) accordingly.

tests/hard_coded/uint64_ground_term.{m,exp}:
    A new test case to check that uint64 values too large to be int64 values
    can be stored in static structures.

tests/hard_coded/Mmakefile:
    Enable the new test case.
2018-05-05 13:22:19 +02:00
Zoltan Somogyi
15aa457e12 Delete $module arg from calls to unexpected. 2018-04-07 18:25:43 +10:00
Zoltan Somogyi
5d9a63ac57 Add ops for creating and accessing 64 bit ints as dwords.
runtime/mercury_int.h:
    Add macros to create double-word int64s/uint64s from two words,
    and to access each word of a double-word int64 or uint64.

    Put the int64 and uint64 versions of the same macro next to each other.

    Add parentheses where this clarifies code.

runtime/mercury_float.h:
    Note the parallel to the new code in mercury_int.h.

    Add comments to #elses and #endifs that repeat the condition of the
    initial #if, to make the code easier to read.

    Put macro definitions into a consistent order.

    Use lower-case names for macro parameters, since this is standard.

    Add parentheses where this clarifies code.

    Delete a macro definition that is now in mercury_std.h.

runtime/mercury_std.h:
    Move a macro here from mercury_float.h, since mercury_int.h now
    uses it too.

runtime/mercury_memory.h:
    Improve some comments.

compiler/builtin_ops.m:
    Add operations to create double-word int64s/uint64s from two words,
    and to access each word of a double-word int64 or uint64.
    These correspond to the new macros in mercury_int.h.
    The new operations are not used yet.

compiler/bytecode.m:
compiler/c_util.m:
compiler/erl_call_gen.m:
compiler/llds.m:
compiler/llds_out_data.m:
compiler/ml_global_data.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/opt_debug.m:
    Conform to the change to builtin_ops.m.
2018-03-28 11:42:24 +11:00
Zoltan Somogyi
60cb13fb06 Use unary ops to access the halves of dwords.
compiler/builtin_ops.m:
    Replace the float_word_bits binary op with two unary ops,
    dword_float_get_word[01]. The unchanged operand represents the address
    of the double word. The only two values of the deleted operand that
    made sense were the constants 0 and 1. Replacing the binary op
    with two unary ops encodes this invariant in the types.

runtime/mercury_float.h:
    Define two new macros/functions, MR_dword_float_get_word[01],
    which get the two halves respectively of a double-word float.
    These are the implementations of the two new unary ops.

compiler/bytecode.m:
compiler/c_util.m:
compiler/erl_call_gen.m:
compiler/llds.m:
compiler/llds_out_data.m:
compiler/llds_out_instr.m:
compiler/ml_global_data.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/opt_debug.m:
compiler/unify_gen.m:
compiler/var_locn.m:
    Conform to the change above.
2018-03-15 23:30:39 +11:00
Julien Fischer
f519e26173 Add builtin 64-bit integer types -- Part 1.
Add the new builtin types: int64 and uint64.

Support for these new types will need to be bootstrapped over several changes.
This is the first such change and does the following:

- Extends the compiler to recognise 'int64' and 'uint64' as builtin types.
- Extends the set of builtin arithmetic, bitwise and relational operators
  to cover the new types.
- Adds the new internal option '--unboxed-int64s' to the compiler; this will be
  used to control whether 64-bit integer types are boxed or not.
- Extends all of the code generators to handle the new types.
- Extends the runtimes to support the new types.
- Adds new modules to the standard library intend to contain basic operations
  on the new types.  (These are currently empty and not documented.)

There are bunch of limitations marks with "XXX INT64"; these will be lifted in
part 2 of this change.  Also, 64-bit integer types are currently always boxed,
again this limitation will be lifted in later changes.

compiler/options.m:
    Add the new option --unboxed-int64s.

compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
     Recognise int64 and uint64 as builtin types.

compiler/builtin_ops.m:
     Add builtin operations for the new types.

compiler/hlds_data.m:
     Add new tag types for the new types.

compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_dependency_graph.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/opt_debug.m:
compiler/opt_util.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_util.m:
compiler/rbmm.execution_path.m:
compiler/rtti.m:
compiler/table_gen.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
    Conform to the above changes to the parse tree and HLDS.

compiler/c_util.m:
    Support writing out constants of the new types.

compiler/llds.m:
    Add a representation for constants of the new types to the LLDS.

compiler/stack_layout.m:
    Add a new field to the stack layout params that records whether
    64-bit integers are boxed or not.

compiler/call_gen.:m
compiler/code_info.m:
compiler/disj_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_instr.m:
compiler/lookup_switch.m:
compiler/mercury_compile_llds_back_end.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/var_locn.m b/compiler/var_locn.m:
    Support the new types in the LLDS code generator.

compiler/mlds.m:
    Support constants of the new types in the MLDS.

compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_global_data.m:
compiler/ml_rename_classes.m:
compiler/ml_top_gen.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
     Conform to the above changes to the MLDS.

compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Generate the appropriate target code for constants of the new types
    and operations involving them.

compiler/bytecode.m:
compiler/bytecode_gen.m:
    Handle the new types in the bytecode generator; we just abort if we
    encounter them for now.

compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_unify_gen.m:
    Handle the new types in the Erlang code generator.

library/private_builtin.m:
    Add placeholders for the builtin unify and compare operations for
    the new types.  Since the bootstrapping compiler will not recognise
    the new types we give them polymorphic arguments.  These can be
    replaced after this change has bootstrapped.

    Update the Java list of TypeCtorRep constants here.

library/int64.m:
library/uint64.m:
    New modules that will eventually contain builtin operations on the new
    types.

library/library.m:
library/MODULES_UNDOC:
    Do not include the above modules in the library documentation for now.

library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
library/table_statistics.m:
deep_profiler/program_representation_utils.m:
mdbcomp/program_representation.m:
    Handle the new types.

configure.ac:
runtime/mercury_conf.h.in:
    Define the macro MR_BOXED_INT64S.  For now it is always defined, support for
    unboxed 64-bit integers will be enabled in a later change.

runtime/mercury_dotnet.cs.in:
java/runtime/TypeCtorRep.java:
runtime/mercury_type_info.h:
    Update the list of type_ctor reps.

runtime/mercury.h:
runtime/mercury_int.[ch]:
    Add macros for int64 / uint64 -> MR_Word conversion, boxing and
    unboxing.

    Add functions for hashing 64-bit integer types suitable for use
    with the tabling mechanism.

runtime/mercury_tabling.[ch]:
    Add additional HashTableSlot structs for 64-bit integer types.

    Omit the '%' character from the conversion specifiers we pass via
    the 'key_format' argument to the macros that generate the table lookup
    function.  This is so we can use the C99 exact size integer conversion
    specifiers (e.g. PRIu64 etc.) directly here.

runtime/mercury_hash_lookup_or_add_body.h:
    Add the '%' character that was omitted above to the call to debug_key_msg.

runtime/mercury_memory.h:
     Add new builtin allocation sites for boxed 64-bit integer types.

runtime/mercury_builtin_types.[ch]:
runtime/mercury_builitn_types_proc_layouts.h:
runtime/mercury_construct.c:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_ml_expand_body.h:
runtime/mercury_table_type_body.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_tabling_preds.h:
runtime/mercury_term_size.c:
runtime/mercury_unify_compare_body.h:
    Add the new builtin types and handle them throughout the runtime.

runtime/Mmakefile:
    Add mercury_int.c to the list of .c files.

doc/reference_manual.texi:
     Add the new types to the list of reserved type names.

     Add the mapping from the new types to their target language types.
     These are commented out for now.
2018-01-12 09:29:24 -05:00
Zoltan Somogyi
7b0ca6345f Encode invariants about class inheritance in types.
compiler/mlds.m:
    Make mlds_interface_id its own type, instead of identifying all
    interfaces by an MLDS type using the mlds_class_type/3 data constructors.

    Make mlds_class_id its own type, instead of identifying (almost all)
    classes by an MLDS type using the mlds_class_type/3 data constructors.

    Change the field of mlds_class_defns that says what base classes the
    class inherits from to reflect the facts that

    - the "classes" representing environments that we put on the heap
      when targeting C# or Java have a base *type*, not a base *class*, and

    - no current MLDS target language supports multiple inheritance,
      so an MLDS class cannot inherit from more than one base class.

    Change the mlds_class_type data constructor of the mlds_type type
    to take a complete mlds_class_id as an argument, instead of its pieces.

compiler/ml_accurate_gc.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_rename_classes.m:
compiler/ml_simplify_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Conform to the changes above.
2017-10-19 19:13:28 +11:00
Zoltan Somogyi
e3a4968746 Delete a misleadingly named type.
compiler/mlds.m:
    Delete the type "mlds_type_name". Despite its name, it is not the name
    of a type in either the HLDS (mer_type) or MLDS (mlds_type) sense;
    it is the name of a class and its arity.

compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_rename_classes.m:
compiler/ml_type_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
    Replace uses of mlds_type_name with the class name and its arity.
    In most cases, the new code is clearer as well as faster (since it avoids
    creating or traversing a memory cell).

    In ml_global_data.m, put some code into into execution order.
2017-10-15 04:34:31 +11:00
Zoltan Somogyi
577cffb940 Make the flags on function and class definitions concrete.
compiler/mlds.m:
    I made the types of flags on the definitions of variables (global,
    local and field) concrete types a while ago. This diff does the same
    for the flags on the definitions of functions and classes.

    The abstraction barrier may have bought us something when the definitions
    of *everything* in the MLDS used the *same* flag type, but it does not buy
    us anything useful anymore, and in fact it makes some things harder to see.

    Rename the access type the function_access type, since only function
    definitions use it now.

compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
    Conform to the change in mlds.m.

    In some places, the diff replaces code that updates some components
    of a flag with code that totally replaces the flag; the abstract nature
    of the old interface hid the fact that the "some components" actually
    were *all* the components.

    Inline the functions that compute values of flags that are called
    from only one place.
2017-10-15 01:39:28 +11:00
Zoltan Somogyi
1c01ed85eb Fix lines. 2017-07-29 14:15:15 +02:00
Zoltan Somogyi
b390231f22 Use mlds_target_lang in the MLDS backend.
The overall compilation target language (which is recorded in the globals)
can be C, Java, C# or Erlang. The target language of the MLDS backend
can only be the first three. Use the mlds_target_lang type (which has
three functors) instead of the compilation_target type (which has four)
to make target-specific decisions in the MLDS backend.

compiler/mercury_compile_mlds_back_end.m:
    Compute the MLDS target (which can be C, Java or C#) from the compilation
    target (which can also be Erlang).

compiler/ml_closure_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_tag_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds.m:
compiler/rtti_to_mlds.m:
    Use the mlds_target_lang value computed in mercury_compile_mlds_back_end.m
    to make decisions. Code in most modules get this from the ml_gen_info;
    in some others, it is passed around, usually instead of the globals.

compiler/ml_code_util.m:
    Unify two separate copies of a comment.
2017-07-27 03:33:20 +02:00
Zoltan Somogyi
c0357f2251 Delete the mlds_defn type along with its last users.
compiler/ml_global_data.m:
    Remove the unnecessary mlds_defn wrapper from the types of vector rows.

compiler/ml_elim_nested.m:
    Replace mlds_defn with another type in an as-yet-unused type.

compiler/mlds.m:
    Delete the mlds_defn type.

compiler/ml_util.m:
    Delete utility functions on the mlds_defn type that aren't needed anymore.

compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Conform to the above.

    Delete now-unused predicates.
2017-07-26 04:39:02 +02:00
Zoltan Somogyi
bb1f7675b5 Store different kinds of definitions in classes separately.
Store the members of an mlds_class_defn in three separate lists, one for
field vars, one for subclasses and one for member functions, to enforce
the invariant that neither local nor global variables can be members.
The slot for member functions is used only by mlds_to_java.m.

compiler/mlds.m:
    Make the change described above.

    Put the field containing ctor functions last.

compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
    Conform to the change above.
2017-07-26 03:40:13 +02:00
Zoltan Somogyi
05433e82ea Don't use "flat" names in ml_global_data.m.
compiler/ml_global_data.m:
    Don't use flat/nonflat as part of the names and description of the
    components of ml_global_data, since (due to their now specialized types)
    this isn't needed anymore.

    Put fields of related types next to each other.

    Delete an unused predicate.

    Delete some old, now-misleading comments.

compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the change above.
2017-07-24 13:39:25 +02:00
Zoltan Somogyi
595014b978 Simplify the flags field in field var definitions.
compiler/mlds.m:
    The field variables we generate are always "public" within the classes
    that define them, so delete the access field from their flags. Field vars
    were the only type left that used the mlds_data_decl_flags type, so rename
    this type to reflect this fact. Make the type concrete, since abstraction
    buys us nothing useful in this case.

compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
    Conform to the change above.
2017-07-23 04:40:40 +02:00
Zoltan Somogyi
4cb6e63597 Simplify the flags field in global var definitions.
compiler/mlds.m:
    Global variables are defined outside classes (except classes that function
    as modules), so the one_copy/per_instance distinction does not make
    sense for them. They also only have two possible levels of access:
    the module, and the whole program. Change the flags field of global
    variables to reflect this. Use a concrete type to represent such flags,
    since abstraction buys us nothing useful in this case.

compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the change above.
2017-07-23 02:45:42 +02:00
Zoltan Somogyi
fa5eee77c5 Specialize qual/3 for each type it was applied to.
The MLDS either module- or type-qualifies several kinds of entities.
It used to use the same qual/3 wrapper for all these entities. However,
many kinds of entities are never (and can never be) type-qualified,
because they are not defined inside a type.

This diff replaces the mlds_fully_qualified_name type, and its qual/3 wrapper,
with a separate type and a separate wrapper for each kind of entity.
For those entities that can be both module- and type-qualified, have this
wrapper continue to include a mlds_qual_kind (module_qual or type_qual) field;
for the entities that are only ever module qualified, omit this field.

compiler/mlds.m:
    Make the change described above.

    There are some related changes.

    The first is that the argument of the ml_field_named rval specifying
    the field used to be a string. Change this to be a field_var_name,
    because if a field's name is given by a field_var_name in its definition,
    it should be given by that same field_var_name in its uses as well.
    Without this, it is unnecessarily hard to ensure that the code that
    generates the target language versions of the field's name match
    in definitions and uses; specification, it would be unnecessarily hard
    to ensure that they do module- or type-qualification the same way.

    The second is required by the first. We used to use "ptr_num"
    as the name of only a compiler-generated local variable, but it is
    actually the name of a field in a compiler-generated class, and the
    local variable use actually refers to the field. Therefore this diff
    moves the reference to this from the mlds_local_var_name type
    to the mlds_field_var_name type.

    The third is switching to a more consistent naming scheme:
    having the unqualified name of entities of kind xxx be mlds_xxx_name
    and the qualified version of those names being qual_xxx_name.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above.

compiler/java_names.m:
    Clarify a variable name.
2017-07-22 22:48:30 +02:00
Zoltan Somogyi
47f1df4a0a Split mlds_data_defn into three separate types.
We used to use mlds_data_defns to represent three related but nevertheless
distinct kinds of entities: global variables, local variables, and fields
in classes. This diff replaces the mlds_data_defn type with three separate
types: mlds_global_var_defn, mlds_local_var_defn and mlds_field_var_defn
respectively, with corresponding changes to related types, such as
mlds_data_name.

The global variables are completely separate from the other two kinds.
Local and field variables are *mostly* separate from each other, but they
are related in one way. When we flatten out nested functions, the child
nested function can no longer access its parent function's local variables,
so we pass those variables to it as fields of an environment structure.
This requires turning local variables to fields of that structure,
and the code in the flattened previously-nested function that accesses
those fields naturally wants to treat them as if they were local variables
(as indeed they sort-of were before the flattening). There are therefore
ways to convert each of local and fields vars into the other.

This restructuring makes clear several invariants of the MLDS we generate
that were previously hidden. For example, variables with certain kinds of
names (in the before-this-diff, general version of the mlds_var_name type)
could appear only as function arguments or as locals in ml_stmt_blocks,
not in ml_global_data, while for some other names the opposite was the case.
And in several cases, functions used to take a general mlds_data_defn
as argument but aborted if given the "wrong kind" of mlds_data_defn.

This diff also makes possible further simplifications. For example,
local vars should not need some flags (since e.g. they are never per-instance),
and should never need either module or type qualification, while global
variables (which are also never per-instance) should never need type
qualification (since they are not fields of a type). The definitions
in blocks should consist of local variables and (before flattening) functions,
not global variables, field variables or classes, while the members in classes
should be only field variables and functions (and maybe classes), not
global or local variables. Those changes will be in future diffs;
this is already large enough.

compiler/mlds.m:
    Make the changes described above.

    Use tighter types where possible.

    Use (a generalized version) of the mlconst_named_const functor
    to represent values of enum types defined in the runtimes
    of the target platforms.

compiler/ml_global_data.m:
    Store *only* global variables in fields that previously stored general
    mlds_datas (that by design were always global).

    Store *only* closure wrapper functions in the previous non-flat-defns
    field. Before this diff, the code generator only put closure wrapper
    functions in this field, but then ml_elim_nested.m put everything
    resulting from the expansion of those functions back into those fields
    as well, some of which were not functions. It now puts those non-function
    things into the MLDS data structure directly.

compiler/ml_code_util.m:
compiler/ml_util.m:
    Conform to the changes above.

    Use tighter types where possible. If appropriate, change the name
    of the function or predicate accordingly.

    Represent references to enum constants defined in the runtime of the
    target language as named constants (since they is what they are),
    instead of representing them as MLDS "variables", which required
    the code of mlds_to_cs.m had to special-case the treatment
    of those "variables".

compiler/ml_elim_nested.m:
    Conform to the changes above.

    Use tighter types where possible.

    Don't put the environment types resulting from flattening nested scopes
    back into the non-flat-defns slot of the ml_elim_info; instead, return
    them separately to code that puts them directly in the MLDS.

compiler/rtti.m:
    When returning the names of enum constants in the C runtime, return also
    the prefixes that you need to place in front of these to obtain their names
    in the Java and C# runtimes.

compiler/mercury_compile_mlds_back_end.m:
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
compiler/rtti_out.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above.

    Move a utility function from ml_util.m to mlds_to_target_util.m,
    since it is used only in mlds_to_*.m.
2017-07-22 00:20:40 +02:00
Julien Fischer
8a240ba3f0 Add builtin 8, 16 and 32 bit integer types -- Part 1.
Add the new builtin types: int8, uint8, int16, uint16, int32 and uint32.
Support for these new types will need to be bootstrapped over several changes.
This is the first such change and does the following:

- Extends the compiler to recognise 'int8', 'uint8', 'int16', 'uint16', 'int32'
  and 'uint32' as builtin types.
- Extends the set of builtin arithmetic, bitwise and relational operators to
  cover the new types.
- Extends all of the code generators to handle new types.  There currently lots
  of limitations and placeholders marked by 'XXX FIXED SIZE INT'.  These will
  be lifted in later changes.
- Extends the runtimes to support the new types.
- Adds new modules to the standard library intended to hold the basic
  operations on the new types.  (These are currently empty and not documented.)

This change does not introduce the two 64-bit types, 'int64' and 'uint64'.
Their implementation is more complicated and is best left to a separate change.

compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
    Recognise int8, uint8, int16, uint16, int32 and uint32 as builtin types.

    Add new type, int_type/0,that enumerates all the possible integer types.

    Extend the cons_id/0 type to cover the new types.

compiler/builtin_ops.m:
    Parameterize the integer operations in the unary_op/0 and binary_op/0
    types by the new int_type/0 type.

    Add builtin operations for all the new types.

compiler/hlds_data.m:
    Add new tag types for the new types.

compiler/hlds_pred.m:
    Parameterize integers in the table_trie_step/0 type.

compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_dependency_graph.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/opt_debug.m:
compiler/opt_util.m:
compiler/parse_tree_out_info.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/prog_util.m:
compiler/rbmm.exection_path.m:
compiler/rtti.m:
compiler/rtti_to_mlds.m:
compiler/switch_util.m:
compiler/table_gen.m:
compiler/type_constraints.m:
compiler/type_ctor_info.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
    Conform to the above changes to the parse tree and HLDS.

compiler/c_util.m:
    Support generating the builtin operations for the new types.

doc/reference_manual.texi:
    Add the new types to the list of reserved type names.

    Add the mapping from the new types to their target language types.
    These are commented out for now.

compiler/llds.m:
    Replace the lt_integer/0 and lt_unsigned functors of the llds_type/0,
    with a single lt_int/1 functor that is parameterized by the int_type/0
    type.

    Add a representations for constants of the new types to the LLDS.

compiler/call_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_global.m:
compiler/llds_out_instr.m:
compiler/lookup_switch.m:
compiler/middle_rec.m:
compiler/peephole.m:
compiler/pragma_c_gen.m:
compiler/stack_layout.m:
compiler/string_switch.m:
compiler/switch_gen.m:
compiler/tag_switch.m:
compiler/trace_gen.m:
compiler/transform_llds.m:
    Support the new types in the LLDS code generator.

compiler/mlds.m:
    Support constants of the new types in the MLDS.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_target_util.m:
    Conform to the above changes to the MLDS.

compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Generate the appropriate target code for constants of the new
    types and operations involving them.

compiler/bytecode.m:
compiler/bytecode_gen.m:
    Handle the new types in the bytecode generator; we just abort if we
    encounter them for now.

compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_rtti.m:
compiler/erl_unify_gen.m:
    Handle the new types in the Erlang code generator.

library/private_builtin.m:
    Add placeholders for the builtin unify and compare operations for
    the new types.  Since the bootstrapping compiler will not recognise
    the new types we give the polymorphic arguments.  These can be
    replaced after this change has bootstrapped.

    Update the Java list of TypeCtorRep constants.

library/int8.m:
library/int16.m:
library/int32.m:
library/uint8.m:
library/uint16.m:
library/uint32.m:
    New modules that will eventually contain builtin operations
    on the new types.

library/library.m:
library/MODULES_UNDOC:
    Do not include the above modules in the library documentation
    for now.

library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
deep_profiler/program_representation_utils.m:
mdbcomp/program_representation.m:
    Handle the new types.

runtime/mercury_dotnet.cs.in:
java/runtime/TypeCtorRep.java:
runtime/mercury_type_info.h:
    Update the list of TypeCtorReps.

configure.ac:
runtime/mercury_conf.h.in:
    Check for the header stdint.h.

runtime/mercury_std.h:
    Include stdint.h; abort if that header is no present.

runtime/mercury_builtin_types.[ch]:
runtime/mercury_builtin_types_proc_layouts.h:
runtime/mercury_construct.c:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_ml_expand_body.h
runtime/mercury_table_type_body.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_tabling_preds.h:
runtime/mercury_term_size.c:
runtime/mercury_unify_compare_body.h:
    Add the new builtin types and handle them throughout the runtime.
2017-07-18 01:31:01 +10:00
Zoltan Somogyi
30ec420984 Fix an anomaly in how in MLDS treats scalar commons.
compiler/mlds.m:
    The MLDS used to have two different ways to refer to scalar common
    data structures. It had an rval for the *name* of the scalar common,
    and an mlds_name for its *address*. The name could then be wrapped up
    inside a mlconst_data_adr function symbol to convert it to rval.

    An mlds_name is intended to be used for the names of data definitions
    in the MLDS, but scalar commons were never defined in this way.
    And the name and address of a scalar common differ in C only by
    the addition of an "&" operator in front, so the fact that they
    had to be processed by different code (due to them having different types)
    *required* double maintenance.

    This diff fixes this anomaly by making both the name and the address
    of a scalar common its own specific function symbol in the mlds_rval type.
    They differ in the presence or absence of an "_addr" suffix.

    Since all references to a vector common are to its address, give
    the existing mlds_rval function symbol for vector commons the "_addr
    suffix as well, for consistency.

    Replace the general mlconst_data_addr function symbol in the
    mlds_rval_const with its remaining instances. This allows the code
    constructing them to be smaller and simpler, and enables them
    to be treated differently in the future, if needed.

compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Conform to the changes in mlds.m.

    Put the code translating the various common structures next to each other,
    where they werent' before. Add XXXs about the differences between them
    that are probably unnecessary and may possibly be latent problems.

compiler/ml_util.m:
    Conform to the changes in mlds.m.

    Change the interface to a set of predicates that looks for variables
    inside various MLDS constructs to take a variable name, not a data name,
    as the thing being looked for.

compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_tailcall.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
    Conform to the changes in mlds.m, and maybe ml_util.m.

    In ml_proc_gen.m, put related arguments of some predicates and functions
    next to each other.
2017-07-13 13:36:51 +02:00
Zoltan Somogyi
083f990dbb Simplify the use of contexts in the MLDS.
compiler/mlds.m:
    This diff fixes two minor annoyances imposed by the old use of the
    mlds_context type in the MLDS.

    The first annoyance was that the mlds_context type used to be an
    abstract type that was privately defined to be a trivial wrapper
    around a prog_context. It had the exact same information content
    as a prog_context, but you had to go through translation functions
    to translate prog_contexts to mlds_contexts and vice versa.
    I think Fergus's idea was that we may want to add other information
    to the mlds_context type. However, since we haven't felt the need
    to anything like that in the 18 years (almost to the day) that the
    mlds_context type existed, I think this turned out to be a classic
    case of YAGNI (you ain't gonna need it).

    This diff deletes the mlds_context type, and replaces its uses
    with prog_context.

    The second annoyance was that actual MLDS code, i.e. values of the
    mlds_stmt type, always had to wrapped up inside a term of the statement
    type, a term which paired a context with the mlds_stmt.

    This diff moves the context information (now prog_context, not
    mlds_context) into each function symbol of the mlds_stmt type,
    deletes the statement type, and replaces its uses with the now-expanded
    mlds_stmt type. This simplifies most code that deals with MLDS code.

compiler/ml_util.m:
    Add a function, get_mlds_stmt_context, for the (very rare) occasions
    where we want to know the context of an mlds_stmt *before* testing
    to see what function symbol it is bound to.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tag_switch.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above.

    In some cases, a function was given two separate contexts, sometimes from
    two separate sources; a prog_context and an mlds_context. In such cases,
    keep only one source.

    Standardize on Stmt as the variable name for "statement".

    Delete redundant $module references from unexpected and other abort
    predicates.

    In one case, delete a function that was a duplicate of another function.

    Give some predicates and functions more meaningful names.
2017-07-09 18:44:05 +02:00
Zoltan Somogyi
95ec3679ff Delete some unneeded old types.
compiler/mlds.m:
    Delete a type, and a function symbol using that type, that was needed
    (and generated) only by the old IL backend.

    Delete the mlds_entity_name type, which has now been superseded by
    the mlds_{data,function,type}_name types.

    Provide mlds_append_class_qualifier_module_qual, a specialized version
    of mlds_append_class_qualifier for module qualified names.

compiler/mlds_to_c.m:
compiler/mlds_to_java.m:
compiler/ml_global_data.m:
compiler/ml_unify_gen.m:
    Delete code that dealt with the type and function symbol deleted from
    mlds.m, and/or use mlds_append_class_qualifier_module_qual where
    appropriate.
2017-07-05 14:00:21 +02:00
Zoltan Somogyi
761de42e28 Tighten the type of flags in mlds_class_defns.
compiler/mlds.m:
    As above.

compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Conform to the change above.
2017-05-31 10:33:47 +02:00
Zoltan Somogyi
91ba5278bc Tighten the type of flags in mlds_data_defns.
compiler/mlds.m:
    As above.

compiler/ml_util.m:
    Delete the predicate that returned the flags of *every* kind of definition
    as a value of a single type.

    Add a utility predicate used by both mlds_to_{cs,java}.m.

    Delete utility predicates all of whose uses in the files below
    this diff replaces with other code.

compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the above.

    In mlds_to_c.m, simplify some other related code.
2017-05-31 01:14:08 +02:00
Zoltan Somogyi
63162fc7e3 Tighten the type of names in mlds_{function,class}_defns.
compiler/mlds.m:
    Make type of the name of an mlds_function_defn not an mlds_entity_name,
    but a bespoke type, mlds_function_name. To make this possible, create
    the mlds_function_name type. This step also documents the fact that
    the old entity_export names always applied to function definitions.

    Make type of the name of an mlds_class_defn not an mlds_entity_name,
    but a bespoke type, mlds_function_name. To make this possible, create
    the mlds_type_name type. (The MLDS backend refers to mlds_class_defns
    sometimes as "classes" and sometimes as "types"; when it handles
    their names, it mostly uses the "type" terminology.)

compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
    Conform to the above: stop wrapping and unwrapping data names.

    In a few places, do some other cleanups.
2017-05-30 18:02:06 +02:00
Zoltan Somogyi
8f58542270 Tighten the type of names in mlds_data_defns.
compiler/mlds.m:
    Make type of the name of an mlds_data_defn not an mlds_entity_name,
    but an mlds_data_name, one of the several possibilities that
    mlds_entity_name chooses amongst. For data definitions, we always
    use a data name.

compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the above: stop wrapping and unwrapping data names.
2017-05-24 11:41:53 +02:00
Zoltan Somogyi
869605956c Make MLDS definitions self-contained.
Until now, we used a single type, mlds_defn, to contain both

- generic information that we need for all MLDS definitions, such as
  name and context, and

- information that is specific to each different kind of MLDS definition,
  such as a variable's initializer or a function's list of parameter types.

The former were contained in three fields in the mlds_defns directly,
while the latter were contained in a fourth field that was a discriminated
union of mlds_data_defn, mlds_function_defn and mlds_class_defn.

While seemingly parsimonious, this design meant that if we had e.g. a list
of variable definitions, we would have to wrap the mlds_defn/4 wrapper around
them to give them their names, and thereafter, any code that processed
that list would have to be prepared to process not just variables but also
functions and classes.

This diff moves the three generic fields into each of the mlds_data_defn,
mlds_function_defn and mlds_class_defn types, making each those types
self-contained, and leaving mlds_defn as nothing more than a discriminated
union of those types.

In the few places that want to look at the generic fields *without*
caring about what kind of entity is being defined, this design requires
a bit of extra work compared to the old design, but in many other places,
the new design allows us to return mlds_data_defns, mlds_function_defns
or mlds_class_defns instead of just mlds_defns.

compiler/mlds.m:
    Make the change described above.

    Store type definions (for high level data) and table structures definitions
    separately from other definitions in the MLDS type, since we can now
    give them tighter types.

compiler/ml_global_data.m:
    Change the fields that store flat cells from storing mlds_defns to
    storing mlds_data_defns, since we can now do so.

    Add an XXX about an obsolete comment.

compiler/mercury_compile_mlds_back_end.m:
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the changes above. Where possible with only local changes,
    return mlds_data_defns mlds_function_defns or mlds_class_defns instead
    of just mlds_defns. Put the mlds_data(_), mlds_function(_) or mlds_class(_)
    wrapper around those definitions as late as possible (typically, when
    our current code wants to put it into the same list as some other kind
    of definition), in the hope that in the future, that wrapping can be
    delayed even later, or even avoided altogether. Make the places where
    such improvements may be possible with "XXX MLDS_DEFN".

    In some places, the tighter data representation allows us to *delete*
    "XXX MLDS_DEFN" markers.

    Move some common code from mlds_to_{cs,java}.m to ml_util.m.

    In mlds_to_{cs,java}.m, add prefixes to the function symbols in a type
    to reduce ambiguity.
2017-05-24 09:45:21 +02:00
Zoltan Somogyi
49fc26b6ff Store the mlds_defns of functions and data in their own types.
compiler/mlds.m:
    The mlds_defn type can store the definition of a piece of data,
    a function, or a class. The information contained in the definition
    of a class was stored in a separate type, but the information stored
    in the other two kinds of definitions weren't, which made it impossible
    to store e.g. a list of just *data* definitions. Fix this by providing
    two types that store the information contains in data and function
    definitions respectively.

compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
    Conform to the change above.
2017-05-21 09:52:29 +02:00
Zoltan Somogyi
aabb240ce0 Simplify the handling of lists of global definitions.
compiler/ml_global_data.m:
    We used to store globals definitions as reversed lists,
    so we could append to the end in O(1) time. However, this design
    requires reversing and later un-reversing lists of definitions
    in some cases. Simplify all this by storing definitions in their
    actual order, and using cords to achieve O(1) complexity for
    appending new definitions.

    Delete some output arguments from a predicate that its only caller
    would ignore anyway.

    Rename the predicates involved in the above to reflect these changes.

    Put the declaration and definitions of the module's predicates
    in the same order.

compiler/ml_elim_nested.m:
    Conform to the changes above.
2017-05-20 17:50:37 +02:00
Zoltan Somogyi
8dbea9f096 Use a structured representation for MLDS variables.
compiler/mlds.m:
    Replace the old definition of mlds_var_name, which was a string
    with an optional integer. The integer was intended to be the number
    of a HLDS variable, while auxiliary variables created by the compiler,
    which do not correspond to a HLDS variable, would not have the optional
    integer.

    This design has a couple of minor problems. The first is that there is
    no place in the compiler where all the variable names are visible at once,
    and without such a place, we cannot be sure that two names constructed
    for different purposes don't accidentally end up with the same name.
    The probability of such a clash used to be astronomically small
    (which is why this hasn't been a problem), but it was not zero.

    The second problem is that several kinds of compiler-created MLDS variables
    want to have numerical suffixes too, usually with the suffix being a
    unique sequence number used as a means of disambiguation. Most of the
    places where these were created put the numerical suffix into the name
    string itself, while some put the sequence number as the optional integer.

    As it happens, neither of those actions is good when one wants to take
    the independently generated MLDS code of several procedures in an SCC
    and merge them into a single piece of MLDS code. For this, we want to
    rename apart both the HLDS variable numbers and the sequence numbers.
    Having the sequence number baked into the strings themselves obviously
    makes such renumbering unnecessarily hard, while having sequence numbers
    in the slots intended for HLDS variable numbers makes the job impossible
    to do safely.

    This diff switches to a new representation of mlds_var_names that
    has a separate function symbol for each different "origin story"
    that is possible for MLDS variables. This addresses both problems.

    The single predicate that converts this structured representation
    to a string is the place where we can ensure that two semantically
    different MLDS variables never get translated to the same string.
    The current version of this predicate does *not* offer this guarantee,
    but later versions could.

    And having all the integers used in mlds_var_names for different purposes
    stored as arguments of different function symbols (that clearly indicate
    their meaning) makes it possible to rename apart different sets
    of MLDS variables easily and reliably.

    Move the code for converting mlds_var_names from ml_code_util.m to here,
    to make it easier to maintain it together with the mlds_var_name type.

compiler/ml_code_util.m:
    Conform to the above change by generating structured MLDS var names.

    Delete a predicate that is not needed with structured var names.

    Delete the code moved to mlds.m.

    Delete a predicate that has been unused since we deleted the IL backend.

    Add ml_make_boxed_type as a version of ml_make_boxed_types that returns
    exactly one type. This simplifies some code elsewhere.

    Add "hld" to some predicate names to make clear that they are intended
    for use only with --high-level-data.

compiler/ml_type_gen.m:
    Conform to the above change by generating structured MLDS var names.

    Add "hld" to the names of the (many) predicates here that are used
    only with --high-level-data to make clear that fact.

compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
    Conform to the above change by generating structured MLDS var names.

    Add a "for_csharp" or "for_java" suffix to some predicate names
    to avoid ambiguities.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_string_switch.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
    Conform to the above change by generating structured MLDS var names.

compiler/prog_type.m:
    Add var_to_type, as a version of var_list_to_type_list that returns
    exactly one type. This simplifies some code elsewhere.

compiler/java_names.m:
    Give some predicates and functions better names.

compiler/ml_code_gen.m:
    Fix typo.
2017-04-24 15:16:36 +10:00
Zoltan Somogyi
63d7101a53 Express some preconditions in types.
compiler/ml_type_gen.m:
    Generate fields for generated structures from a bespoke type.
    This allows us to express the preconditions of several predicates
    in the types of their inputs, instead of as executable tests that aborted
    the compiler if they failed.

    Inline a predicate at the only place it was used.

compiler/ml_global_data.m:
    Conform to the above change.
2017-04-20 14:28:04 +10:00
Julien Fischer
fe297f25f5 Add more builtin ops on uints (part 1).
compiler/builtin_ops.m:
     Add unchecked left and right shifts for uints as well
     as the reverse modes of addition and subtraction.

library/uint.m:
     Add commented out mode declarations for addition and
     subtraction; they can be uncommented once the above
     has bootstrapped.

compiler/bytecode.m:
compiler/c_util.m:
compiler/erl_call_gen.m:
compiler/llds.m:
compiler/llds_out_data.m:
compiler/ml_global_data.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/opt_debug.m:
     Conform to the above changes.
2017-04-11 14:11:22 +10:00
Zoltan Somogyi
b96dacdcac Make a bunch of switches complete.
compiler/exception_analysis.m:
compiler/frameopt.m:
compiler/get_dependencies.m:
compiler/labelopt.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/options_file.m:
compiler/parse_class.m:
compiler/rtti.m:
compiler/rtti_out.m:
compiler/type_util.m:
compiler/var_locn.m:
    As above.

compiler/inst_match.m:
    Fix a stray piece of code.

compiler/loop_inv.m:
    Add a module qualification.

compiler/opt_util.m:
    Delete two unused predicates.
2017-03-09 13:43:48 +11:00
Julien Fischer
ff592131b3 Add a builtin unsigned word sized integer type -- Part 1b.
compiler/builtin_ops.m:
    Implement unchecked_quotient, unchecked_rem, /\, \/, xor and \
    as builtin operations.

compiler/bytecode.m:
compiler/c_util.m:
compiler/llds.m:
compiler/llds_out_data.m:
compiler/ml_global_data.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/opt_debug.m:
     Conform to the above change.

compiler/ml_unify_gen.m:
    Fix a bug in my previous change: we should use uint_eq to test
    for equality of uints, not eq.

compiler/hlds_data.m:
     Document uint_tag/1.

runtime/mercury_tabling_macros.h:
     Address review comment from Peter.

runtime/mercury_tabling_preds.h:
     Add tabling macros for uints that I missed the first time around.
2016-10-25 23:56:52 +11:00
Julien Fischer
092e175f45 Add a builtin unsigned word sized integer type -- Part 1.
Add a new builtin type: uint, which is an unsigned word sized integer type.
Support for this new type will need be bootstrapped over several changes.
This is the first such change and does the following:

- Extends the compiler to recognize 'uint' as a builtin type.
- Extends the set of builtin operations to include relational and (some)
  arithmetic operations on uints.
- Extends all of the code generators to handle the above.  There are some
  limitations currently marked by 'XXX UINT'.  These will be lifted once
  the compiler recognised uint and additional library support becomes
  available.
- Extends the runtime to support uints.

compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
    Recognize uint as a builtin type.

    Add a new alternative to the cons_id/0 type corresponding to the uint type
    -- for bootstrapping purposes its argument is currently an int.

compiler/builtin_ops.m:
    Add builtin relational and arithmetic operations on uints.  Note that the
    existing 'unsigned_le' operation is actually intended for use with signed
    values.  Rather than attempt to modify its meaning, I have just added new
    operations specific to the uint type.

compiler/hlds_data.m:
    Add a new tag type for uints.

compiler/type_ctor_info.m:
    Recognise uint as a builtin.

    Bump the RTTI version number here.

compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/dependency_graph.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/hlds_pred.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/prog_util.m:
compiler/rbmm.execution_path.m:
compiler/rtti.m:
compiler/special_pred.m:
compiler/switch_gen.m:
compiler/switch_util.m:
compiler/table_gen.m:
compiler/type_constraints.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/write_module_interface_files.m:
compiler/xml_documentation.m:
    Conform to the above changes to the parse tree and HLDS.

compiler/c_util.m:
    Support generating builtin operations for uints.

compiler/llds.m:
    Add a representation for uint constants to the LLDS.

    Map uints onto MR_Unsigned.

compiler/call_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_instr.m:
compiler/opt_debug.m:
compiler/opt_util.m:
    Support uints in the LLDS code generator.

compiler/mlds.m:
     Support uint constants in the MLDS.

compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_global_data.m:
compiler/ml_simplify_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/rtti_to_mlds.m:
    Conform to the above change to the MLDS.

compiler/mlds_to_c.m:
compiler/mlds_to_java.m:
compiler/mlds_to_cs.m:
     Generate the appropriate target code for uint constants and uint
     relational operations.

compiler/bytecode.m:
compiler/bytecode_gen.m:
     Handle uints in the bytecode generator: we just abort if we
     encounter them for now.

compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_rtti.m:
compiler/erl_unify_gen.m:
    Handle uints in the Erlang code generator.

library/private_builtin.m:
    Add placeholders for builtin_{unify,compare}_uint.  Since the
    bootstrapping compiler will not recognize uint as a type, we
    give them polymorphic arguments.  These can be replaced after
    this change has bootstrapped.

    Update the Java list of TypeCtorRep constants, which for some
    reason is defined here.

library/uint.m:
    New module that will eventually contain operations on uints.

library/MODULES_DOCS:
library/library.m:
     Add the uint module.

library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
mdbcomp/program_representation.m:
     Handle uints.

deep_profiler/program_representation_utils.m:
     Conform to the above change.

runtime/mercury_dotnet.cs.in:
     Update the list of TypeCtorReps for C#

java/runtime/TypeCtorRep.java:
     Update this, although the actual TypeCtorRep constants
     are defined the library.

runtime/mercury_type_info.h:
    Bump the RTTI version number.

    Add an alternative for uints to the tyepctor rep enum.

runtime/mercury_builtin_types.{h,c}:
runtime/mercury_builtin_types_proc_layouts.h:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_table_type_body.h:
runtime/mercury_tabling.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_unify_compare_body.h:
    Add uint as a builtin type and handle it throughout the runtime.

runtime/mercury_grade.h:
    Bump the binary compatibility version.

runtime/mercury_term_size.c:
runtime/mercury_ml_expand_body.h:
    Handle uint and fix probable bugs with the handling of ints on
    64-bit Windows.
2016-10-24 12:55:35 +11:00
Zoltan Somogyi
cc9912faa8 Don't import anything in packages.
Packages are modules whose only job is to serve as a container for submodules.
Modules like top_level.m, hlds.m, parse_tree.m and ll_backend.m are packages
in this (informal) sense.

Besides the include_module declarations for their submodules, most of the
packages in the compiler used to import some modules, mostly other packages
whose component modules their submodules may need. For example, ll_backend.m
used to import parse_tree.m. This meant that modules in the ll_backend package
did not have to import parse_tree.m before importing modules in the parse_tree
package.

However, this had a price. When we add a new module to the parse_tree package,
parse_tree.int would change, and this would require the recompilation of ALL
the modules in the ll_backend package, even the ones that did NOT import ANY
of the modules in the parse_tree package.

This happened even at one remove. Pretty much all modules in every one
of the backend have to import one or more modules in the hlds package,
and they therefore have import hlds.m. Since hlds.m imported transform_hlds.m,
any addition of a new middle pass to the transform_hlds package required
the recompilation of all backend modules, even in the usual case of the two
having nothing to do with each other.

This diff removes all import_module declarations from the packages,
and replaces them with import_module declarations in the modules that need
them. This includes only a SUBSET of their child modules and of the non-child
modules that import them.
2015-11-13 15:03:20 +11:00
Julien Fischer
3dd02876a5 Delete the MLDS->IL backend.
compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
compiler/mlds_to_managed.m:
compiler/il_peephole.m:
compiler/ilasm.m:
compiler/ilds.m:
    Delete the modules making up the MLDS->IL code generator.

compiler/globals.m:
compiler/prog_data.m:
    Delete IL as a target and foreign language.

compiler/prog_io_pragma.m:
    Delete the max_stack_size/1 foreign proc attribute.  This was only
    ever required by the IL backend.

compiler/options.m
    Delete options used for the IL backend.

compiler/write_deps_file.m:
    Don't generate mmake targets for .il files etc.

compiler/*.m:
    Conform to the above changes.

compiler/notes/compiler_design.html
compiler/notes/work_in_progress.html
    Conform to the above changes.

library/*.m:
    Delete IL foreign_proc and foreign_export pragmas.

README.DotNet:
    Delete this file.

browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
runtime/Mmakefile:
slice/Mmakefile:
    Conform the above changes.

configure.ac:
    Don't check that IL is a supported foreign language when performing the
    up-to-date check.

    Delete the '--enable-dotnet-grades' option.

scripts/Mmake.vars.in:
    Delete variables used for the IL backend (and in on case by the Aditi
    backend).

scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
scripts/Mmake.rules:
scripts/canonical_grade.sh-subr:
tools/bootcheck:
    Delete stuff related to the 'il' and 'ilc' grades.

doc/reference_manual.texi:
     Delete the documentation of the 'max_stack_size' option.

doc/user_guide.texi:
     Delete stuff related to the IL backend.

tests/hard_coded/csharp_test.{m,exp}:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/valid/csharp_hello.m:
	Delete these tests: they are no longer relevant.

tests/hard_coded/equality_pred_which_requires_boxing.m:
tests/hard_coded/foreign_import_module.m:
tests/hard_coded/foreign_import_module_2.m:
tests/hard_coded/foreign_type.m:
tests/hard_coded/foreign_type2.m:
tests/hard_coded/foreign_type3.m:
tests/hard_coded/intermod_foreign_type2.m:
tests/hard_coded/lp.m:
tests/hard_coded/user_compare.m:
tests/invalid/foreign_type_2.m:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/invalid/foreign_type_visibility.m:
tests/invalid/illtyped_compare.{m,err_exp}:
tests/submodules/external_unification_pred.m
tests/valid/big_foreign_type.m
tests/valid/solver_type_bug.m
tests/valid_seq/foreign_type_spec.m
tests/valid_seq/intermod_impure2.m
    Delete IL foreign_procs where necessary.

tests/hard_coded/Mmakefile
tests/invalid/Mercury.options
tests/invalid/Mmakefile
tests/submodules/Mmakefile
tests/valid/Mercury.options
tests/valid/Mmake.valid.common
tests/valid/Mmakefile
tests/valid_seq/Mmakefile
tests/valid_seq/Mercury.options
    Conform to the above changes.
2015-09-21 11:34:46 +10:00
Zoltan Somogyi
7654ec847e Convert (C->T;E) to (if C then T else E). 2015-09-18 09:37:29 +10:00
Zoltan Somogyi
62ec97d443 Report imports shadowed by other imports.
If a module has two or more import_module or use_module declarations
for the same module, (typically, but not always, one being in its interface
and one in its implementation), generate an informational message about
each redundant declaration if --warn-unused-imports is enabled.

compiler/hlds_module.m:
    We used to record the set of imported/used modules, and the set of
    modules imported/used in the interface of the current module. However,
    these sets

    - did not record the distinction between imports and uses;
    - did not allow distinction between single and multiple imports/uses;
    - did not record the locations of the imports/uses.

    The first distinction was needed only by module_qual.m, which *did*
    pay attention to it; the other two were not needed at all.

    To generate messages for imports/uses shadowing other imports/uses,
    we need all three, so change the data structure storing such information
    for *direct* imports to one that records all three of the above kinds
    of information. (For imports made by read-in interface and optimization
    files, the old set of modules approach is fine, and this diff leaves
    the set of thus *indirectly* imported module names alone.)

compiler/unused_imports.m:
    Use the extra information now available to generate a
    severity_informational message about any import or use that is made
    redundant by an earlier, more general import or use.

    Fix two bugs in the code that generated warnings for just plain unused
    modules.

    (1) It did not consider that a use of the builtin type char justified
    an import of char.m, but without that import, the type is not visible.

    (2) It scanned cons_ids in goals in procedure bodies, but did not scan
    cons_ids that have been put into the const_struct_db. (I did not update
    the code here when I added the const_struct_db.)

    Also, add a (hopefully temporary) workaround for a bug in
    make_hlds_passes.m, which is noted below.

    However, there are at least three problems that prevent us from enabling
    --warn-unused-imports by default.

    (1) In some places, the import of a module is used only by clauses for
    a predicate that also has foreign procs. When compiled in a grade that
    selects one of those foreign_procs as the implementation of the predicate,
    the clauses are discarded *without* being added to the HLDS at all.
    This leads unused_imports.m to generate an uncalled-for warning in such
    cases. To fix this, we would need to preserve the Mercury clauses for
    *all* predicates, even those with foreign procs, and do all the semantic
    checks on them before throwing them away. (I tried to do this once, and
    failed, but the task should be easier after the item list change.)

    (2) We have two pieces of code to generate import warnings. The one in
    unused_imports.m operates on the HLDS after type and mode checking,
    while module_qual.m operates on the parse tree before the creation of
    the HLDS. The former is more powerful, since it knows e.g. what types and
    modes are used in the bodies of predicates, and hence can generate warnings
    about an import being unused *anywhere* in a module, as opposed to just
    unused in its interface.

    If --warn-unused-imports is enabled, we will get two separate set of
    reports about an interface import being unused in the interface,
    *unless* we get a type or mode error, in which case unused_imports.m
    won't be invoked. But in case we do get such errors, we don't want to
    throw away the warnings from module_qual.m. We could store them and
    throw them away only after we know we won't need them, or just get
    the two modules to generate identical error_specs for each warning,
    so that the sort_and_remove_dups of the error specs will do the
    throwing away for us for free, if we get that far.

    (3) The valid/bug100.m test case was added as a regression test for a bug
    that was fixed in module_qual.m. However the bug is still present in
    unused_imports.m.

compiler/make_hlds_passes.m:
    Give hlds_module.m the extra information it now needs for each item_avail.

    Add an XXX for a bug that cannot be fixed right now: the setting of
    the status of abstract instances to abstract_imported. (The "abstract"
    part is correct; the "imported" part may not be.)

compiler/intermod.m:
compiler/try_expand.m:
compiler/xml_documentation.m:
    Conform to the change in hlds_module.m.

compiler/module_qual.m:
    Update the documentation of the relationship of this module
    with unused_imports.m.

compiler/hlds_data.m:
    Document a problem with the status of instance definitions.

compiler/hlds_out_module.m:
    Update the code that prints out the module_info to conform to the change
    to hlds_module.m.

    Print status information about instances, which was needed to diagnose
    one of the bugs in unused_imports.m. Format the output for instances
    nicer.

compiler/prog_item.m:
    Add a convenience predicate.

compiler/prog_data.m:
    Remove a type synonym that makes things harder to understand, not easier.

compiler/modules.m:
    Delete an XXX that asks for the feature this diff implements.
    Add another XXX about how that feature could be improved.

compiler/Mercury.options.m:
    Add some more modules to the list of modules on which the compiler
    should be invoked with --no-warn-unused-imports.

compiler/*.m:
library/*.m:
mdbcomp/*.m:
browser/*.m:
deep_profiler/*.m:
mfilterjavac/*.m:
    Delete unneeded imports. Many of these shadow other imports, and some
    are just plain unneeded, as shown by --warn-unused-imports. In a few
    modules, there were a *lot* of unneeded imports, but most had just
    one or two.

    In a few cases, removing an import from a module, because it *itself*
    does not need it, required adding that same import to those of its
    submodules which *do* need it.

    In a few cases, conform to other changes above.

tests/invalid/Mercury.options:
    Test the generation of messages about import shadowing on the existing
    import_in_parent.m test case (although it was also tested very thoroughly
    when giving me the information needed for the deletion of all the
    unneeded imports above).

tests/*/*.{m,*exp}:
    Delete unneeded imports, and update any expected error messages
    to expect the now-smaller line numbers.
2015-08-25 00:38:49 +10:00
Zoltan Somogyi
d041b83943 Implement string switches via tries for the MLDS backend.
The code we emit to decide which arm of the switch is selected looks like this:

    case_num = -1;
    switch (MR_nth_code_unit(switchvar, 0)) {
        case '98':
            switch (MR_nth_code_unit(switchvar, 1)) {
                case '99':
                    if (MR_offset_streq(2, switchvar, "abc"))
                        case_num = 0;
                    break;
                case '100':
                    if (MR_offset_streq(2, switchvar, "aceg"))
                        case_num = 1;
                    break;
            }
            break;
        case '99':
            if (MR_offset_streq(2, switchvar, "bbb"))
                case_num = 2;
            break;
    }

The part that acts on this will look like this for lookup switches:

    if (case_num < 0)
        succeeded = MR_FALSE;
    else {
        outvar1 = vector_common[case_num].f1;
        ...
        outvarn = vector_common[case_num].fn;
        succeeded = MR_TRUE;
    }

and like this for non-lookup switches:

    switch (case_num) {
    case 0:
        <code for case 0>
        break;
    ...
    case n:
        <code for case n>
        break;
    default:                    /* if the switch is can_fail */
        <code for failure>
        break;
    }

compiler/ml_string_switch.m:
    Implement both non-lookup and lookup string switches via tries,
    along the lines shown above.

compiler/ml_switch_gen.m:
    Invoke the predicates that implement string switches via tries
    in the circumstances in which option values call for them.

    For now, we generate tries only for the C backend. Once the
    problems identified for mlds_to_{cs,java,managed} below are fixed,
    we can enable them on those backends as well.

compiler/options.m:
doc/user_guide.texi:
    Add an option that governs the minimum size of trie switches.

compiler/ml_lookup_switch.m:
    Factor out the code common to the implementation of all model-non
    lookup switches, both in ml_lookup_switch.m and ml_string_switch.m,
    and put it all into a new exported predicate.

    The previously existing MLDS implementation methods for lookup switches
    all build their lookup tables from maps that maps each cons_id
    in the switch cases to the values of the output arguments of those cases.
    For switch cases that apply to more than one cons_id, this map had
    one entry for each of those cons_ids. For tries, we need a map
    from *case ids*, not *cons ids* to the outputs. Since it is
    easier to convert the one-to-one case_id->outputs map to the
    many-to-one cons_id->outputs map than vice versa, change the
    main data structure from which lookup tables are built to store data
    in a case_id->outputs format, and provide predicates for its conversion
    to the other (previously the only) format.

    Rename ml_gen_lookup_switch to ml_gen_atomic_lookup_swith to distinguish
    it from other predicates that also generate (other kinds of) lookup
    switches.

compiler/switch_util.m:
    Have the types representating lookup tables represent their contents
    as a map, not as the assoc list derived from the map. Previously,
    we didn't do anything with the map other than flatten it to the assoc list,
    but for the MLDS backend, we may now also need to convert it to another
    form of map (see immediately above).

compiler/builtin_ops.m:
    Add two new builtin ops. The first, string_unsafe_index_code_unit,
    returns the nth code unit in a string; the second, offset_str_eq,
    does a string equality test on the nth and later code units of
    two strings. They are used in the implementation of tries.

compiler/c_util.m:
    Add a new binop category for each new binop, since they are not like
    existing binops.

    Put some existing binops into their own categories as well, since
    bundling them with the other ops they were bundled with seems like
    a bad idea.

compiler/hlds_goal.m:
    Make the identifier of switch arms in tagged_cases a separate type
    from int.

compiler/mlds_to_c.m:
compiler/llds_out_data.m:
    Handle the new kinds of binops.

    When writing out binop expressions, we used to do a switch on the binop
    to get its category, and then another switch on the category. We now
    switch on the binop directory, since this much harder to write out
    code using new binops badly, and should be faster to boot.

    In mlds_to_c.m, also make some cosmetic changes to the output to make it
    easier to read, and thus to debug.

compiler/mlds_to_il.m:
    Handle the new kinds of binops.

compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_managed.m:
    Do not handle the new kinds of binops, since doing so would require
    changing the whole approach of how these modules handle binops.

    Clean up some predicates.

compiler/bytecode.m:
compiler/erl_call_gen.m:
compiler/lookup_switch.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_tag_switch.m:
compiler/opt_debug.m:
compiler/string_switch.m:
    Conform to the changes above.

compiler/ml_code_gen.m:
    Put the predicates of this module into a consistent order.

library/string.m:
    Fix white space.

runtime/mercury_string.h:
    Add a macro for each of the two new builtin operations.
2015-02-24 16:03:30 +11:00