Files
mercury/mdbcomp
Zoltan Somogyi 8303b503b6 Unify and compare packed args in bulk when possible.
compiler/unify_proc.m:
    Try to optimize the code we generate for unification and comparison
    predicates when a function symbol's arguments include sub-word-sized
    arguments packed together into a word.

    For unify predicates, generate code to test whether the two words
    at the same offset in the terms being unified are equal. This works
    regardless of whether the arguments are signed or unsigned.

    For compare predicates, generate code to compare the two words
    at the same offset in the terms being compared *if* all the arguments
    in the terms being compared are unsigned. This works because we put
    the earlier arguments in the more significant bit positions. But if
    some of the arguments are signed, then divide the argument word
    in sequences of zero or more unsigned arguments separated by signed
    arguments. We then generate code that compares any contiguous sequences
    of unsigned arguments in bulk, while comparing each signed field
    separately.

    Do the bulk unification and comparison via foreign_proc goals generated
    inline. This works only when we are generating C, but this is ok because
    we pack sub-word-sized arguments into a word only when generating C.

    We do the comparison of signed sub-word-sized fields (int8, int16 or int32)
    via foreign_proc goals generated inline as well. Doing them using unify
    goals would work as well, but would be less efficient in general. This is
    because having N such arguments in a function symbols requires storing
    only one value across calls for each term being compared (the term itself)
    when generating foreign_procs, but would require storing N values across
    calls (the values of the sub-word-sized signed arguments) when generating
    unifications. Generating inline foreign_procs is effectively a manual
    application of the optimization implemented by saved_vars.m.

library/private_builtin.m:
    Add the builtin predicates that unify_proc.m now generates calls to.

    We should never need their bodies, but the compiler does need to know
    the declarations of all predicates mentioned in inline foreign_procs.

configure.ac:
runtime/mercury_conf.h.in:
    Define either MR_MERCURY_IS_32_BITS or MR_MERCURY_IS_64_BITS depending
    on the word size. Make the configured value of MR_BITS_PER_WORD available
    to C code.

mdbcomp/program_representation.m:
    Register the new builtin predicates as no_typeinfo_builtins, i.e.
    builtins whose arguments' types contain type variables, that nevertheless
    should *not* be passed the typeinfos of the actual types bound to those
    type variables.

compiler/hlds_clauses.m:
    Bulk unification of arguments works only when all the arguments involved
    are initially ground. The optimized unification clauses we can now generate
    are thus appropriate only for <in,in> unifications. (Technically, they
    *would* work for unifications for which the function symbol arguments
    involved in bulk unify operations are ground even if some other arguments
    are initially free, but that distinction is too hard to make, compared
    to the extremely small performance gain that would be available
    if we *could* make that distinction.)

    Provide a way for unify_proc.m to mark a clause as being for use either
    in the <in,in> modes of unifications (for the optimized version using bulk
    unifications), or as in all other modes of unifications (for a version in
    which that optimization has been disabled).

    Replace two boolean fields in clauses_infos with bespoke types, for
    greater readability and reliability. These are a remnant of a different
    way to differentiate <in,in> vs non-<in,in> clauses that I ultimately
    decided against. These bespoke types are independent of the main change
    in this diff, but there is no reason to undo their use.

compiler/clause_to_proc.m:
    When copying clauses to procedure bodies inside type-specific unify
    predicates, pay attention to the markers that unify_proc.m put on
    those clauses about which are for <in,in> modes and which are for
    non-<in,in> modes.

    To make this possible, make our callers pass us extra information.

compiler/options.m:
    Add a bootstrapping option that governs whether unify_proc.m should
    try to apply the new optimization.

    Give an option that governs comparisons of function symbols for Erlang
    a name that reflects that fact.

compiler/hlds_pred.m:
    Fix a misleading predicate name.

compiler/add_class.m:
compiler/add_clause.m:
compiler/add_foreign_proc.m:
compiler/add_pragma_type_spec.m:
compiler/add_pred.m:
compiler/dead_proc_elim.m:
compiler/det_report.m:
compiler/erl_code_gen.m:
compiler/handle_options.m:
compiler/higher_order.m:
compiler/hlds_out_module.m:
compiler/hlds_out_pred.m:
compiler/hlds_statistics.m:
compiler/intermod.m:
compiler/mercury_compile_front_end.m:
compiler/ml_proc_gen.m:
compiler/modecheck_unify.m:
compiler/proc_gen.m:
compiler/proc_requests.m:
compiler/purity.m:
compiler/resolve_unify_functor.m:
compiler/structure_reuse.indirect.m:
compiler/structure_sharing.analysis.m:
compiler/tabling_analysis.m:
compiler/type_constraints.m:
compiler/typecheck.m:
compiler/unused_args.m:
    Conform to the changes above.
2018-10-03 08:32:29 +10:00
..
2018-08-08 21:17:12 +10:00