mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-18 19:03:45 +00:00
083d376e6598628362ee91c2da170febd83590f4
71 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
d273494121 | Rename a functor to avoid ambiguity. | ||
|
|
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.)
|
||
|
|
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.
|
||
|
|
b6d4d3f30d | Fix more issues reported by --warn-inconsistent-pred-order-clauses. | ||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
15aa457e12 | Delete $module arg from calls to unexpected. | ||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
1c01ed85eb | Fix lines. | ||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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.
|
||
|
|
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. |
||
|
|
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.
|
||
|
|
7654ec847e | Convert (C->T;E) to (if C then T else E). | ||
|
|
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.
|
||
|
|
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.
|