mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-17 18:33:58 +00:00
083d376e6598628362ee91c2da170febd83590f4
127 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Zoltan Somogyi
|
f7442dbb1a |
Change some "arity"s to "pred_form_arity"s.
compiler/hlds_rtti.m:
compiler/mlds.m:
As above.
compiler/add_pragma_tabling.m:
compiler/ml_accurate_gc.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_util.m:
compiler/mlds_dump.m:
compiler/mlds_to_c_class.m:
compiler/mlds_to_c_data.m:
compiler/mlds_to_c_file.m:
compiler/mlds_to_c_func.m:
compiler/mlds_to_c_name.m:
compiler/mlds_to_c_stmt.m:
compiler/mlds_to_cs_name.m:
compiler/mlds_to_java_name.m:
compiler/proc_label.m:
compiler/rtti_to_mlds.m:
Conform to the changes above.
Simplify some code that does output.
Delete some no-longer-relevant comments.
|
||
|
Zoltan Somogyi
|
3e894a7a9d |
Remove the hl grade component.
As we discussed, it has fallen into disuse. Its main purpose was to
pave the way for the .net backend and later for the java and csharp grades.
Now that the .net backend is ancient history and the java and csharp grades
are established, that purpose is gone, and for every other purpose,
hlc is better because it is simpler and faster.
compiler/options.m:
Delete the --high-level-data option. It is no longer needed,
bacause the data representation scheme is now a direct function
of the target language.
doc/user_guide.texi:
Delete references to the --high-level-data option.
NEWS:
Mention that --high-level-data is no longer supported.
compiler/compute_grade.m:
Delete references to the hl grade component, and conform
to the deletion of the --high-level-data option.
compiler/compile_target_code.m:
Give some predicates more meaningful names, and conform to the
deletion of the --high-level-data option.
compiler/const_struct.m:
compiler/du_type_layout.m:
compiler/globals.m:
compiler/handle_options.m:
compiler/lco.m:
compiler/mercury_compile_main.m:
compiler/ml_gen_info.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen_construct.m:
compiler/mlds_to_c_data.m:
compiler/mlds_to_c_func.m:
compiler/mlds_to_c_type.m:
compiler/mlds_to_c_util.m:
Conform to the deletion of the --high-level-data option.
grade_lib/grade_spec.m:
grade_lib/grade_vars.m:
Delete the datarep solver variable, since the data representation
is now a direct function of the target language.
Delete the requirements involving the deleted solver variable.
grade_lib/grade_structure.m:
Delete the datarep component of the representation of MLDS C grades,
since its value would now be fixed.
grade_lib/grade_solver.m:
grade_lib/grade_string.m:
grade_lib/try_all_grade_structs.m:
grade_lib/var_value_names.m:
Conform to the changes above.
grade_lib/Mmakefile:
Link the grade library's test programs statically, like we do
the executables in the other directories.
library/io.m:
library/robdd.m:
library/rtti_implementation.m:
runtime/mercury_conf_param.h:
runtime/mercury_grade.h:
runtime/mercury_hlc_types.h:
Remove references to MR_HIGHLEVEL_DATA, as well as any code
that was guarded by #ifdef MR_HIGHLEVEL_DATA.
scripts/Mmake.vars.in:
scripts/canonical_grade.sh-subr:
scripts/final_grade_options.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/mgnuc_file_opts.sh-subr:
scripts/mmake.in:
scripts/mmc.in:
scripts/mtc:
scripts/parse_grade_options.sh-subr:
scripts/parse_ml_options.sh-subr.in:
Remove references to --high-level-data options.
In canonical_grade.sh-subr, compute the base grade more directly.
Remove a few left-over references to the assembler backend.
Add or fix vim modelines where relevant.
Fix inconsistent indentation.
Add missing ;;s in case statements.
Switch to using ${var} references instead of just $var.
tests/invalid/Mercury.options:
Make the test_feature_set test case run in grade java instead of hl.gc.
tests/invalid/test_feature_set.err_exp:
Update the expected out for the grade change.
|
||
|
Peter Wang
|
5f7d3e6bb2 |
Use consistent integer types for some RTTI fields.
runtime/mercury_type_info.h:
Use unsigned integer types for a few RTTI structure fields that
are known to hold non-negative values.
Add comments for other field types that could be changed later.
compiler/rtti.m:
Use fixed size integer types for fields matching the size
and signedness of the corresponding C RTTI structure fields.
Encode type ctor flags in a uint16 instead of int.
Make type_ctor_details_num_ptags and type_ctor_details_num_functors
return a maybe value, instead of a negative value to represent no
primary tags or no function symbols, respectively.
compiler/type_ctor_info.m:
Conform to type changes.
Use uint16 to represent the "contains var" bit vector.
compiler/rtti_out.m:
compiler/rtti_to_mlds.m:
Conform to type changes.
Add comments to make it easier to find the code that writes out
each particular RTTI structure field.
compiler/ml_util.m:
Add helper functions.
compiler/add_special_pred.m:
compiler/du_type_layout.m:
compiler/erl_rtti.m:
compiler/erlang_rtti.m:
compiler/hlds_data.m:
compiler/llds_out_data.m:
compiler/ml_unify_gen_construct.m:
compiler/opt_debug.m:
compiler/pseudo_type_info.m:
compiler/stack_layout.m:
compiler/unify_gen_construct.m:
Conform to type changes.
compiler/parse_type_defn.m:
compiler/prog_data.m:
Use uint32 for functor ordinal numbers.
library/rtti_implementation.m:
Use fixed size integer types for RTTI field accessor functions,
and update callers.
java/runtime/DuArgLocn.java:
java/runtime/DuExistInfo.java:
java/runtime/DuExistLocn.java:
java/runtime/DuFunctorDesc.java:
java/runtime/TypeCtorInfo_Struct.java:
Use integer types in RTTI structure definitions for Java that match
the types in the C versions of the same structures.
runtime/mercury_dotnet.cs.in:
Use integer types in RTTI structure definitions for C# that match
the types in the C versions of the same structures.
|
||
|
Zoltan Somogyi
|
b66f45e4db |
Tighten the mlds_type type.
compiler/mlds.m:
Make two changes to mlds_type.
The simpler change is the deletion of the maybe(foreign_type_assertions)
field from the MLDS representations of Mercury types. It was never used,
because Mercury types that are defined in a foreign language that is
acceptable for the current MLDS target platform are represented
as mlds_foreign_type, not as mercury_type.
The more involved change is to change the representation of builtin types.
Until now, we had separate function symbols in mlds_type to represent
ints, uints, floats and chars, but not strings or values of the sized
types {int,uint}{8,16,32,64}; those had to be represented as Mercury types.
This is an unnecessary inconsistency. It also had two allowed
representations for ints, uints, floats and chars, which meant that
some of the code handling those conceptual types had to be duplicated
to handle both representations.
This diff provides mlds_builtin_type_{int(_),float,string,char} function
symbols to represent every builtin type, and changes mercury_type
to mercury_nb_type to make clear that it is NOT to be used for builtins
(the nb is short for "not builtin").
compiler/ml_code_util.m:
compiler/ml_util.m:
Delete functions that used to construct MLDS representations of builtin
types. The new representation of those types is so simple that using
such functions is no less cumbersome than writing down the representations
directly.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_proc_gen.m:
compiler/ml_rename_classes.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tag_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen_construct.m:
compiler/ml_unify_gen_deconstruct.m:
compiler/ml_unify_gen_util.m:
compiler/mlds_dump.m:
compiler/mlds_to_c_data.m:
compiler/mlds_to_c_export.m:
compiler/mlds_to_c_func.m:
compiler/mlds_to_c_global.m:
compiler/mlds_to_c_stmt.m:
compiler/mlds_to_c_type.m:
compiler/mlds_to_cs_data.m:
compiler/mlds_to_cs_stmt.m:
compiler/mlds_to_cs_type.m:
compiler/mlds_to_java_data.m:
compiler/mlds_to_java_stmt.m:
compiler/mlds_to_java_type.m:
compiler/mlds_to_java_wrap.m:
compiler/rtti_to_mlds.m:
Conform to the changes above.
|
||
|
Zoltan Somogyi
|
ec6a40ed85 |
Put related args of ml_field next to each other.
compiler/mlds.m:
Put the *type* of the pointer next to the *value* of the pointer.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.m:
compiler/ml_string_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_unused_assign.m:
compiler/ml_util.m:
compiler/mlds_dump.m:
compiler/mlds_to_c_data.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.
|
||
|
Zoltan Somogyi
|
d3fd088aea |
Pack args using unsigned arithmetic.
compiler/ml_unify_gen.m:
Do ORs and shifts on argument values being packed using MR_Unsigned.
Cast the results to MR_Box explicitly.
compiler/ml_util.m:
Add utility functions that return (static terms containing) the MLDS
representations of the builtin integer types.
compiler/mlds_to_c_data.m:
Parenthesize values being cast, to ensure that the cast applies
to the *whole* of the value, not just an initial part. (For example,
"(uint32_t) x >> 32" casts just x, not the result of the shift.)
tests/hard_coded/pack_int32.{m,exp}:
A regression test for the bug report that this diff addresses.
tests/hard_coded/Mmakefile:
Add the new test case.
|
||
|
Zoltan Somogyi
|
b9afc8b78e |
Delete the mlds_unary_op type.
compiler/mlds.m:
We used to have a function symbol ml_unop in the mlds_rval type
that applied one of four kinds of operations to an argument mlds_rval:
boxing, unboxing, casting or a standard unary operation, with a value
of type mlds_unary_op selecting between the four. Replace this system
with four separate function symbols in the mlds_rval type directly,
and delete the mlds_unary_op type.
The new arrangement requires fewer memory cells to be allocated,
and less indirection; it also leads to shorter and somewhat
more readable code.
compiler/ml_optimize.m:
Conform to the change above.
Recognize that a cast has negligible cost.
compiler/ml_code_util.m:
Conform to the change above.
Keep private a predicate that is not used by any other module,
after merging it with another previously-exported predicate
that only *it* uses.
Delete some other predicates that are not used anywhere.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_rename_classes.m:
compiler/ml_string_switch.m:
compiler/ml_tag_switch.m:
compiler/ml_unify_gen.m:
compiler/ml_unused_assign.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
fcefbb948d |
Delete assignments to dead variables in the MLDS.
At the moment, we tend not to generate such assignments, with the exception
of assignments to the MLDS versions of HLDS variables of dummy types.
The reason I am nevertheless adding this optimization is that I intend
to soon add code to ml_unify_gen.m that *will* generate assignments
to dead variables.
The idea is to optimize field updates involving packed arguments.
Given a type such as
:- type t
---> f(
f1 :: bool,
f2 :: bool,
f3 :: enum1,
f4 :: int
).
we currently implement a field update such as "T = T0 ^ f4 := 42",
whose HLDS representation is the two unifications
T0 = f(T0f1, T0f2, T0f3, _),
T = f(T0f1, T0f2, T0f3, 42)
using code that looks like this:
T0f1 = (T0[0] >> ...) & ...
T0f2 = (T0[0] >> ...) & ...
T0f3 = (T0[0] >> ...) & ...
T = allocate memory for new memory cell, put on primary tag
T[0] = (T0f1 << ...) | (T0f2 << ...) | (T0f3 << ...)
T[1] = 42
I want to implement it using code that looks like this:
T0w0 = T0[0]
T = allocate memory for new memory cell, put on primary tag
T[0] = T0w0
T[1] = 42
where T0w0 contains the entire first word of the memory cell of T0.
This code avoids a bunch of shifts, ORs and ANDs.
I propose to translate the T0 = f(T0f1, T0f2, T0f3, _) unification into
T0w0 = T0[0]
T0f1 = (T0[0] >> ...) & ...
T0f2 = (T0[0] >> ...) & ...
T0f3 = (T0[0] >> ...) & ...
while recording in the ml_gen_info/code_info that this *specific* packing of
T0f1, T0f2 and T0f3 is available in T0w0. When translating the following
unification, the code generator will see this, and this will allow it to
generate
T[0] = T0w0
instead of
T[0] = (T0f1 << ...) | (T0f2 << ...) | (T0f3 << ...)
However, by this time the assignments to T0f1, T0f2 and T0f3 have already
been generated. Whether or not they are dead assignments depends on whether
other code needs the values of those fields of T0. Deciding this
requires knowledge that the code generator can't have when translating
the deconstruction of T0. Hence the need for a new MLDS-to-MLDS optimization.
compiler/ml_unused_assign.m:
A new compiler module implementing the new optimization.
It is not part of ml_optimize.m because ml_optimize.m traverses
the MLDS forwards, while this optimization requires a backwards traversal:
you cannot know whether an assignment is dead unless you know that the
following code does not need the value of the variable it assigns to.
compiler/ml_backend.m:
compiler/notes/compiler_design.html:
Include the new module.
compiler/mlds.m:
The new optimization needs extra information about loops.
When it enters into the loop body, it knows which variables
are needed *after* the loop, but it does not know which variables
the loop body first reads and then writes. Without this knowledge,
it would optimize away assignments to loop control variables,
such as the increment of i in the loop
i = 0;
while (...) {
...; i = i+1; ...
}
Traditionally, compilers have solved this problem by doing fixpoint
iteration, adding to the live set at each program point until
no more additions are possible. We can do better, because we generate
loops in the MLDS in only two kinds of cases:
- loops implementing tail recursion, in which case the only extra
variables that we need to preserve assignments to in the loop body
are the input arguments of the procedure, and
- loops created by the compiler itself to loop over a set of alternatives,
for which the only extra variables that we need to preserve assignments
to in the loop body are the variables the compiler uses to control
the loop.
To make it possible for ml_unused_assign.m to do its job without
a fixpoint iteration, include in the MLDS representation of every
while loop a list of these variables.
Add a type to represent the identify of an MLDS local var,
for use by some of the modules below. They used to store this info
in the form of mlds_lvals, but that is not specific enough
to be used to fill in the new field in while loops.
compiler/ml_proc_gen.m:
Compute the information needed by the new pass, and invoke it
if the relevant option is set.
compiler/options.m:
Add this option. It is for developers only, so it is undocumented.
compiler/ml_util.m:
Add a utility function needed in several places.
compiler/ml_accurate_gc.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.m:
compiler/ml_string_switch.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 changes in mlds.m.
|
||
|
Zoltan Somogyi
|
8d0597f97d |
Use typed rvals in the MLDS code generator.
compiler/mlds.m:
Introduce the concept of typed rvals to the MLDS (it is already present
in the LLDS).
To start with, use typed rvals to represent the arguments of the new_object
operation.
compiler/ml_accurate_gc.m:
compiler/ml_closure_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.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 change in the new_object operation. In most places,
this means replacing two lists (one of rvals, and one of types)
that had to have the same length, with one list of typed rvals.
The use of typed rvals thus encodes a required invariant in the
type of the data, making its violation impossible. It also means
that many places that used to require iterating on two lists
simultaneously can be replaced by a simple iteration on one list only.
|
||
|
Zoltan Somogyi
|
4b98f58d9d |
Don't use reserved addresses to represent functors.
Late last year, we agreed to delete the ability to use the addresses
of reserved objects as cons_tags. After another (very short) discussion
on m-dev, this diff also deletes the ability to use small integers
(including zero) acting as pointers.
compiler/options.m:
Delete the --num-reserved-addresses option.
Add a synomym for --compiler-sufficiently-recent, with the intention
that support for the representation of reserved addresses in RTTI
code in the runtime will be deleted when all installed compilers
have this new synonym.
compiler/hlds_data.m:
Delete any mention of the reserved addresses from the cons_tag type,
since we don't have reserved addresses anymore.
Don't record for each type whether it uses reserved addresses;
no type can do so anymore.
compiler/rtti.m:
Delete the part of the RTTI representation that dealt with reserved
addresses.
compiler/add_foreign_enum.m:
compiler/add_special_pred.m:
compiler/bytecode_gen.m:
compiler/code_info.m:
compiler/du_type_layout.m:
compiler/equiv_type_hlds.m:
compiler/erl_rtti.m:
compiler/export.m:
compiler/hlds_out_module.m:
compiler/intermod.m:
compiler/ml_switch_gen.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/opt_debug.m:
compiler/prog_data.m:
compiler/rtti_out.m:
compiler/rtti_to_mlds.m:
compiler/structure_reuse.direct.choose_reuse.m:
compiler/switch_gen.m:
compiler/switch_util.m:
compiler/type_ctor_info.m:
compiler/type_util.m:
compiler/unify_gen.m:
Conform to the changes above, mostly by deleting code that used to deal
with reserved addresses.
|
||
|
Julien Fischer
|
f519e26173 |
Add builtin 64-bit integer types -- Part 1.
Add the new builtin types: int64 and uint64.
Support for these new types will need to be bootstrapped over several changes.
This is the first such change and does the following:
- Extends the compiler to recognise 'int64' and 'uint64' as builtin types.
- Extends the set of builtin arithmetic, bitwise and relational operators
to cover the new types.
- Adds the new internal option '--unboxed-int64s' to the compiler; this will be
used to control whether 64-bit integer types are boxed or not.
- Extends all of the code generators to handle the new types.
- Extends the runtimes to support the new types.
- Adds new modules to the standard library intend to contain basic operations
on the new types. (These are currently empty and not documented.)
There are bunch of limitations marks with "XXX INT64"; these will be lifted in
part 2 of this change. Also, 64-bit integer types are currently always boxed,
again this limitation will be lifted in later changes.
compiler/options.m:
Add the new option --unboxed-int64s.
compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
Recognise int64 and uint64 as builtin types.
compiler/builtin_ops.m:
Add builtin operations for the new types.
compiler/hlds_data.m:
Add new tag types for the new types.
compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_dependency_graph.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/opt_debug.m:
compiler/opt_util.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_util.m:
compiler/rbmm.execution_path.m:
compiler/rtti.m:
compiler/table_gen.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
Conform to the above changes to the parse tree and HLDS.
compiler/c_util.m:
Support writing out constants of the new types.
compiler/llds.m:
Add a representation for constants of the new types to the LLDS.
compiler/stack_layout.m:
Add a new field to the stack layout params that records whether
64-bit integers are boxed or not.
compiler/call_gen.:m
compiler/code_info.m:
compiler/disj_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_instr.m:
compiler/lookup_switch.m:
compiler/mercury_compile_llds_back_end.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/var_locn.m b/compiler/var_locn.m:
Support the new types in the LLDS code generator.
compiler/mlds.m:
Support constants of the new types in the MLDS.
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_global_data.m:
compiler/ml_rename_classes.m:
compiler/ml_top_gen.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
Conform to the above changes to the MLDS.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Generate the appropriate target code for constants of the new types
and operations involving them.
compiler/bytecode.m:
compiler/bytecode_gen.m:
Handle the new types in the bytecode generator; we just abort if we
encounter them for now.
compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_unify_gen.m:
Handle the new types in the Erlang code generator.
library/private_builtin.m:
Add placeholders for the builtin unify and compare operations for
the new types. Since the bootstrapping compiler will not recognise
the new types we give them polymorphic arguments. These can be
replaced after this change has bootstrapped.
Update the Java list of TypeCtorRep constants here.
library/int64.m:
library/uint64.m:
New modules that will eventually contain builtin operations on the new
types.
library/library.m:
library/MODULES_UNDOC:
Do not include the above modules in the library documentation for now.
library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
library/table_statistics.m:
deep_profiler/program_representation_utils.m:
mdbcomp/program_representation.m:
Handle the new types.
configure.ac:
runtime/mercury_conf.h.in:
Define the macro MR_BOXED_INT64S. For now it is always defined, support for
unboxed 64-bit integers will be enabled in a later change.
runtime/mercury_dotnet.cs.in:
java/runtime/TypeCtorRep.java:
runtime/mercury_type_info.h:
Update the list of type_ctor reps.
runtime/mercury.h:
runtime/mercury_int.[ch]:
Add macros for int64 / uint64 -> MR_Word conversion, boxing and
unboxing.
Add functions for hashing 64-bit integer types suitable for use
with the tabling mechanism.
runtime/mercury_tabling.[ch]:
Add additional HashTableSlot structs for 64-bit integer types.
Omit the '%' character from the conversion specifiers we pass via
the 'key_format' argument to the macros that generate the table lookup
function. This is so we can use the C99 exact size integer conversion
specifiers (e.g. PRIu64 etc.) directly here.
runtime/mercury_hash_lookup_or_add_body.h:
Add the '%' character that was omitted above to the call to debug_key_msg.
runtime/mercury_memory.h:
Add new builtin allocation sites for boxed 64-bit integer types.
runtime/mercury_builtin_types.[ch]:
runtime/mercury_builitn_types_proc_layouts.h:
runtime/mercury_construct.c:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_ml_expand_body.h:
runtime/mercury_table_type_body.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_tabling_preds.h:
runtime/mercury_term_size.c:
runtime/mercury_unify_compare_body.h:
Add the new builtin types and handle them throughout the runtime.
runtime/Mmakefile:
Add mercury_int.c to the list of .c files.
doc/reference_manual.texi:
Add the new types to the list of reserved type names.
Add the mapping from the new types to their target language types.
These are commented out for now.
|
||
|
Zoltan Somogyi
|
234501be75 |
Remove ml_tailcall.m and associated code.
Now that we can optimize tail recursion for all MLDS targets better via
the MLDS code generator than via ml_tailcall.m, we don't need it anymore.
compiler/ml_tailcall.m:
Delete this module.
compiler/ml_backend.m:
compiler/notes/compiler_design.html:
Delete the inclusion and the documentation of the deleted module.
compiler/mark_tail_calls.m:
Update old references to the deleted module, as well as some comments.
compiler/mercury_compile_mlds_back_end.m:
Don't invoke the deleted module.
compiler/options.m:
Delete the (developer-only) options that used to control whether
we did tail call optimization (TCO) via ml_tailcall.m or not.
compiler/ml_optimize.m:
Delete the parts of this module that worked in concert with ml_tailcall.m
to implement TCO.
compiler/mlds.m:
Delete the field from ml_call_stmts that was needed only by ml_tailcall.m.
compiler/ml_call_gen.m:
Don't fill in the deleted field.
Shift here the only part of the old contents of ml_tailcall.m that is
still needed, the check for whether rvals would become dangling references
if we discarded the current call's stack frame.
compiler/ml_elim_nested.m:
Conform to the change to mlds.m, and eliminate an unused field
in elim_info.
compiler/ml_accurate_gc.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_proc_gen.m:
compiler/ml_rename_classes.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 changes above.
|
||
|
Zoltan Somogyi
|
dad5c99140 |
Delete the attribute field in MLDS function definitions.
compiler/mlds.m:
Delete the attribute field in MLDS function definitions, because
we have never used it.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Delete the code that ignored the attribute field in function definitions
*without* writing it out.
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
Delete code that filled in this field.
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.m:
compiler/ml_tailcall.m:
compiler/ml_util.m:
compiler/mlds_to_target_util.m:
Delete code that copied this field around.
|
||
|
Zoltan Somogyi
|
034cb97988 |
Don't module- or type-qualify MLDS local variables.
Some global variables generated by the MLDS backend need to be visible
across module boundaries, and therefore mlds_data definitions, which
contained global as well as other variables, used to have their names
qualified; usually module-qualified, though sometimes type-qualified.
However, since the diff that partitioned mlds_data_defns into the
definitions of local variables, global variables and field variables,
the qualification of local variables has *not* been necessary, so this diff
removes such qualifications. This makes the MLDS code generating references
to local variables simpler, more readable, and slightly faster.
The generated code is also shorter and easier to read.
There are two exceptional cases in which local variables *did* need
qualification, both of which stretch the meaning of "local".
One such case is the "local" variable dummy_var, which (by definition)
is only ever assigned to, and never used. It is also never defined
in MLDS-generated code; instead, it is defined defined in private_builtin.m
(for the Java and C# backends) or the runtime (for C). All three backends
currently require references to this variable in the runtime to be module
qualified. There are three possible fixes to this problem, which is caused
by the fact that this "local" variable is in fact global.
- Fix 1a would be to make dummy_vars global, not local.
- Fix 1b is to special-case dummy_vars in mlds_to_{c,cs,java}.m, and put
the fixed "private_builtin" qualifier in front of it.
- Fix 1c would be to modify the compiler to never generate any references
to dummy vars at all.
This diff uses fix 1b, because it is simple. I (zs) will explore fix 1c
in the future, and see if it is viable.
The second such case occurs when generating code for unifications
involving function symbols represented by the addresses of reserved objects.
These addresses used to be represented as the addresses of mlds_data
definitions, then as addresses of field variables cast as qualified
local variables. Since diff this makes all local variables unqualified,
this can't continue. Two possible fixes are
- Fix 2a: introduce an mlds const rval representing the address of a field
variable, which solves the problem because unlike local variables,
field variables can still be either module- or type-qualified.
- Fix 2b: prohibit the use of the addresses of reserved objects as tags.
After a (short) discussion on m-dev, this diff uses fix 2b.
compiler/mlds.m:
Delete the qual_local_var_name type, and replace all its uses
with the mlds_local_var_name type. Delete the module qualifier field
in mlds_data_addr_local_var consts.
compiler/ml_code_util.m:
Simplify the predicates and functions whose task is to build references
to local variables. Delete the arguments that they don't need anymore.
Delete one function entirely, since calling it now takes both more
characters and more code than its shortened body does.
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_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.m:
compiler/ml_string_switch.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:
compiler/rtti_to_mlds.m:
Conform to the changes above. Stop qualifying local variable names,
and stop passing the parameters that used to be used *only* for
qualifying local variable names.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the changes above, and implement fix 1b.
NEWS:
compiler/options.m:
compiler/make_tags.m:
Implement fix 2b by disabling the --num-reserved-objects option.
This ensures that we don't use the addresses of reserved objects as tags.
library/private_builtin.m:
Move the C# definition of dummy_var next to the Java definition,
and fix the comments on them.
|
||
|
Zoltan Somogyi
|
c3d8d7a1a7 |
Fix two problems related to function names.
The first problem is that the MLDS constructs that defined functions and
the MLDS constructs that take the addresses of functions used different
data types to *name* those functions. The translations of these constructs
to each target language had to generate the same target language code,
but they did so via two (or in some cases more) separate pieces of code.
The second problem is that the MLDS functions that implement HLDS procedures,
and the auxiliary functions that are sometimes needed to help implement
those procedures, were not delineated as clearly as is they should be.
compiler/mlds.m:
To (mostly) fix the first problem, define the mlds_func_label type,
and use it to identify MLDS functions in both function definitions
and in the mlds_code_addr type that represents a reference to a function.
A full fix will require function definitions to use *qualified*
mlds_func_labels, as the mlds_code_addrs already do. However,
the problem that MLDS definitions are not qualified applies not just
to functions but to other entities as well, and is therefore better fixed
separately.
To fix the second problem, introduce the mlds_maybe_aux_func_id type.
This also addresses an old XXX by providing explicit ways to represent
gc trace functions for both auxiliary and non-auxiliary MLDS functions.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_gen_info.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_rename_classes.m:
compiler/ml_tailcall.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:
compiler/rtti_to_mlds.m:
Conform to the above.
|
||
|
Zoltan Somogyi
|
bd3fd38c0d |
Delete the field for the "this" rval in MLDS calls.
This field of type maybe(mlds_rval) was *always* set to "no".
compiler/mlds.m:
As above.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_rename_classes.m:
compiler/ml_tailcall.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.
|
||
|
Zoltan Somogyi
|
1c01ed85eb | Fix lines. | ||
|
Zoltan Somogyi
|
c0357f2251 |
Delete the mlds_defn type along with its last users.
compiler/ml_global_data.m:
Remove the unnecessary mlds_defn wrapper from the types of vector rows.
compiler/ml_elim_nested.m:
Replace mlds_defn with another type in an as-yet-unused type.
compiler/mlds.m:
Delete the mlds_defn type.
compiler/ml_util.m:
Delete utility functions on the mlds_defn type that aren't needed anymore.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the above.
Delete now-unused predicates.
|
||
|
Zoltan Somogyi
|
bb1f7675b5 |
Store different kinds of definitions in classes separately.
Store the members of an mlds_class_defn in three separate lists, one for
field vars, one for subclasses and one for member functions, to enforce
the invariant that neither local nor global variables can be members.
The slot for member functions is used only by mlds_to_java.m.
compiler/mlds.m:
Make the change described above.
Put the field containing ctor functions last.
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
11c232f060 |
Store different kinds of definitions in blocks separately.
An ml_stmt_block contains some definitions and some statements.
The definitions were traditionally stored in a single list of mlds_defns,
but lots of code knew that some kinds of mlds_defns just couldn't occur
in blocks. This diff, by storing the definitions of (a) local variables
and (b) continuation functions in separate field in ml_stmt_blocks,
gets the type system to enforce the invariant that other kinds of definitions
can't occur in blocks.
This also allows the compiler to do less work, since definitions
don't have to wrapped and then later unwrapped, and code that wants to look
at only e.g. the function definitions in a block don't have to traverse
the definitions of local variables (of which there are many more).
compiler/mlds.m:
Make the change described above.
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_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_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 change above. This allows us to avoid lots of wrapping
up definitions.
In some cases, after this change, we don't need to process mlds_defns
*in general*, which leaves the predicates that used to do that,
and some of the predicates that they used to call, unused. Delete these.
In code that generated MLDS code, consistently use names containing
the word "Defn", instead of "Decl", for variables that contain
mlds_local_var_defns or mlds_function_defns. Some such predicates
generate lists of both local var definition and function definitions,
but most generate only one, and some generate neither.
|
||
|
Zoltan Somogyi
|
8125cd5af7 |
Require MLDS class constructors to be functions.
compiler/mlds.m:
Make the change above.
compiler/ml_elim_nested.m:
compiler/ml_optimize.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/mlds_to_target_util.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
c3bc2a8f0d |
Don't wrap and then unwrap MLDS defns being written out.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
The top levels of these modules used to work by taking the MLDS structure
and its global data component, which contained several lists of mlds_defns,
and then (a) concatenating them into a single big list, and then (b)
partitioning that big list into the various kinds of definitions.
Previous diffs specialized the lists in the MLDS and global data structures
so they contain lists not of mlds_defns, but of mlds_global_var_defns,
mlds_function_defns or mlds_class_defns, but they converted them all
to mlds_defns (wrapping up each definition), and appended them all together
into a single giant list before partitioning that list as before
(which then unwrapped those definitions).
This diff avoids this redundant wrapping/unwrapping. The known types
and sources of the definitions stored in each component of the MLDS
do a large part of the partitioning without any tests, with a
significantly smaller number of runtime tests being required
to complete the partitioning task. This is conceptually cleaner,
and should be faster, both because it avoids some memory allocations,
and because it avoids switching on the kind of each definition.
A related change is that we now don't do any searches for local variables
of particular types (which are needed on some backends on the definitions
within block statements) on lists of *global* definitions, on which they
cannot possibly succeed.
compiler/ml_util.m:
Delete the test predicates we used to use for partitioning.
Some are still needed, but they are now in mlds_to_target_util.m,
since they are never used from anywhere except the above three files.
Delete the predicates that collect method pointers in definitions.
Since they are never used from anywhere except the above three files,
this diff moves them to mlds_to_target_util.m.
compiler/mlds_to_target_util.m:
Move the still-needed partitioning predicates here, in the type-specialized
form in which they are now needed.
Move the predicates that collect method pointers in definitions here,
also in the type-specialized form in which they are now needed.
Adapt the interface to mlds_to_{c,cs,java}.m to account for the fact that
these modules need to collect environment variables in more than one
list of function definitions.
|
||
|
Zoltan Somogyi
|
595014b978 |
Simplify the flags field in field var definitions.
compiler/mlds.m:
The field variables we generate are always "public" within the classes
that define them, so delete the access field from their flags. Field vars
were the only type left that used the mlds_data_decl_flags type, so rename
this type to reflect this fact. Make the type concrete, since abstraction
buys us nothing useful in this case.
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
4cb6e63597 |
Simplify the flags field in global var definitions.
compiler/mlds.m:
Global variables are defined outside classes (except classes that function
as modules), so the one_copy/per_instance distinction does not make
sense for them. They also only have two possible levels of access:
the module, and the whole program. Change the flags field of global
variables to reflect this. Use a concrete type to represent such flags,
since abstraction buys us nothing useful in this case.
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
59b2a7c110 |
Delete the flags field from local var definitions.
compiler/mlds.m:
The flags field of the mlds_local_var_defn type was always set
to the same value, so it contained no information. Delete it.
(The field contained information in its original home in the
mlds_data_defn type; it distinguished local variables from
global and field variables.)
compiler/ml_code_util.m:
Delete the function that returned the value we always used to put
into the now-deleted field.
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the changes above.
|
||
|
Zoltan Somogyi
|
fa5eee77c5 |
Specialize qual/3 for each type it was applied to.
The MLDS either module- or type-qualifies several kinds of entities.
It used to use the same qual/3 wrapper for all these entities. However,
many kinds of entities are never (and can never be) type-qualified,
because they are not defined inside a type.
This diff replaces the mlds_fully_qualified_name type, and its qual/3 wrapper,
with a separate type and a separate wrapper for each kind of entity.
For those entities that can be both module- and type-qualified, have this
wrapper continue to include a mlds_qual_kind (module_qual or type_qual) field;
for the entities that are only ever module qualified, omit this field.
compiler/mlds.m:
Make the change described above.
There are some related changes.
The first is that the argument of the ml_field_named rval specifying
the field used to be a string. Change this to be a field_var_name,
because if a field's name is given by a field_var_name in its definition,
it should be given by that same field_var_name in its uses as well.
Without this, it is unnecessarily hard to ensure that the code that
generates the target language versions of the field's name match
in definitions and uses; specification, it would be unnecessarily hard
to ensure that they do module- or type-qualification the same way.
The second is required by the first. We used to use "ptr_num"
as the name of only a compiler-generated local variable, but it is
actually the name of a field in a compiler-generated class, and the
local variable use actually refers to the field. Therefore this diff
moves the reference to this from the mlds_local_var_name type
to the mlds_field_var_name type.
The third is switching to a more consistent naming scheme:
having the unqualified name of entities of kind xxx be mlds_xxx_name
and the qualified version of those names being qual_xxx_name.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the changes above.
compiler/java_names.m:
Clarify a variable name.
|
||
|
Zoltan Somogyi
|
47f1df4a0a |
Split mlds_data_defn into three separate types.
We used to use mlds_data_defns to represent three related but nevertheless
distinct kinds of entities: global variables, local variables, and fields
in classes. This diff replaces the mlds_data_defn type with three separate
types: mlds_global_var_defn, mlds_local_var_defn and mlds_field_var_defn
respectively, with corresponding changes to related types, such as
mlds_data_name.
The global variables are completely separate from the other two kinds.
Local and field variables are *mostly* separate from each other, but they
are related in one way. When we flatten out nested functions, the child
nested function can no longer access its parent function's local variables,
so we pass those variables to it as fields of an environment structure.
This requires turning local variables to fields of that structure,
and the code in the flattened previously-nested function that accesses
those fields naturally wants to treat them as if they were local variables
(as indeed they sort-of were before the flattening). There are therefore
ways to convert each of local and fields vars into the other.
This restructuring makes clear several invariants of the MLDS we generate
that were previously hidden. For example, variables with certain kinds of
names (in the before-this-diff, general version of the mlds_var_name type)
could appear only as function arguments or as locals in ml_stmt_blocks,
not in ml_global_data, while for some other names the opposite was the case.
And in several cases, functions used to take a general mlds_data_defn
as argument but aborted if given the "wrong kind" of mlds_data_defn.
This diff also makes possible further simplifications. For example,
local vars should not need some flags (since e.g. they are never per-instance),
and should never need either module or type qualification, while global
variables (which are also never per-instance) should never need type
qualification (since they are not fields of a type). The definitions
in blocks should consist of local variables and (before flattening) functions,
not global variables, field variables or classes, while the members in classes
should be only field variables and functions (and maybe classes), not
global or local variables. Those changes will be in future diffs;
this is already large enough.
compiler/mlds.m:
Make the changes described above.
Use tighter types where possible.
Use (a generalized version) of the mlconst_named_const functor
to represent values of enum types defined in the runtimes
of the target platforms.
compiler/ml_global_data.m:
Store *only* global variables in fields that previously stored general
mlds_datas (that by design were always global).
Store *only* closure wrapper functions in the previous non-flat-defns
field. Before this diff, the code generator only put closure wrapper
functions in this field, but then ml_elim_nested.m put everything
resulting from the expansion of those functions back into those fields
as well, some of which were not functions. It now puts those non-function
things into the MLDS data structure directly.
compiler/ml_code_util.m:
compiler/ml_util.m:
Conform to the changes above.
Use tighter types where possible. If appropriate, change the name
of the function or predicate accordingly.
Represent references to enum constants defined in the runtime of the
target language as named constants (since they is what they are),
instead of representing them as MLDS "variables", which required
the code of mlds_to_cs.m had to special-case the treatment
of those "variables".
compiler/ml_elim_nested.m:
Conform to the changes above.
Use tighter types where possible.
Don't put the environment types resulting from flattening nested scopes
back into the non-flat-defns slot of the ml_elim_info; instead, return
them separately to code that puts them directly in the MLDS.
compiler/rtti.m:
When returning the names of enum constants in the C runtime, return also
the prefixes that you need to place in front of these to obtain their names
in the Java and C# runtimes.
compiler/mercury_compile_mlds_back_end.m:
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
compiler/rtti_out.m:
compiler/rtti_to_mlds.m:
Conform to the changes above.
Move a utility function from ml_util.m to mlds_to_target_util.m,
since it is used only in mlds_to_*.m.
|
||
|
Julien Fischer
|
8a240ba3f0 |
Add builtin 8, 16 and 32 bit integer types -- Part 1.
Add the new builtin types: int8, uint8, int16, uint16, int32 and uint32.
Support for these new types will need to be bootstrapped over several changes.
This is the first such change and does the following:
- Extends the compiler to recognise 'int8', 'uint8', 'int16', 'uint16', 'int32'
and 'uint32' as builtin types.
- Extends the set of builtin arithmetic, bitwise and relational operators to
cover the new types.
- Extends all of the code generators to handle new types. There currently lots
of limitations and placeholders marked by 'XXX FIXED SIZE INT'. These will
be lifted in later changes.
- Extends the runtimes to support the new types.
- Adds new modules to the standard library intended to hold the basic
operations on the new types. (These are currently empty and not documented.)
This change does not introduce the two 64-bit types, 'int64' and 'uint64'.
Their implementation is more complicated and is best left to a separate change.
compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
Recognise int8, uint8, int16, uint16, int32 and uint32 as builtin types.
Add new type, int_type/0,that enumerates all the possible integer types.
Extend the cons_id/0 type to cover the new types.
compiler/builtin_ops.m:
Parameterize the integer operations in the unary_op/0 and binary_op/0
types by the new int_type/0 type.
Add builtin operations for all the new types.
compiler/hlds_data.m:
Add new tag types for the new types.
compiler/hlds_pred.m:
Parameterize integers in the table_trie_step/0 type.
compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_dependency_graph.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/opt_debug.m:
compiler/opt_util.m:
compiler/parse_tree_out_info.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/prog_util.m:
compiler/rbmm.exection_path.m:
compiler/rtti.m:
compiler/rtti_to_mlds.m:
compiler/switch_util.m:
compiler/table_gen.m:
compiler/type_constraints.m:
compiler/type_ctor_info.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/xml_documentation.m:
Conform to the above changes to the parse tree and HLDS.
compiler/c_util.m:
Support generating the builtin operations for the new types.
doc/reference_manual.texi:
Add the new types to the list of reserved type names.
Add the mapping from the new types to their target language types.
These are commented out for now.
compiler/llds.m:
Replace the lt_integer/0 and lt_unsigned functors of the llds_type/0,
with a single lt_int/1 functor that is parameterized by the int_type/0
type.
Add a representations for constants of the new types to the LLDS.
compiler/call_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_global.m:
compiler/llds_out_instr.m:
compiler/lookup_switch.m:
compiler/middle_rec.m:
compiler/peephole.m:
compiler/pragma_c_gen.m:
compiler/stack_layout.m:
compiler/string_switch.m:
compiler/switch_gen.m:
compiler/tag_switch.m:
compiler/trace_gen.m:
compiler/transform_llds.m:
Support the new types in the LLDS code generator.
compiler/mlds.m:
Support constants of the new types in the MLDS.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_code_util.m:
compiler/ml_disj_gen.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_target_util.m:
Conform to the above changes to the MLDS.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Generate the appropriate target code for constants of the new
types and operations involving them.
compiler/bytecode.m:
compiler/bytecode_gen.m:
Handle the new types in the bytecode generator; we just abort if we
encounter them for now.
compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_rtti.m:
compiler/erl_unify_gen.m:
Handle the new types in the Erlang code generator.
library/private_builtin.m:
Add placeholders for the builtin unify and compare operations for
the new types. Since the bootstrapping compiler will not recognise
the new types we give the polymorphic arguments. These can be
replaced after this change has bootstrapped.
Update the Java list of TypeCtorRep constants.
library/int8.m:
library/int16.m:
library/int32.m:
library/uint8.m:
library/uint16.m:
library/uint32.m:
New modules that will eventually contain builtin operations
on the new types.
library/library.m:
library/MODULES_UNDOC:
Do not include the above modules in the library documentation
for now.
library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
deep_profiler/program_representation_utils.m:
mdbcomp/program_representation.m:
Handle the new types.
runtime/mercury_dotnet.cs.in:
java/runtime/TypeCtorRep.java:
runtime/mercury_type_info.h:
Update the list of TypeCtorReps.
configure.ac:
runtime/mercury_conf.h.in:
Check for the header stdint.h.
runtime/mercury_std.h:
Include stdint.h; abort if that header is no present.
runtime/mercury_builtin_types.[ch]:
runtime/mercury_builtin_types_proc_layouts.h:
runtime/mercury_construct.c:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_ml_expand_body.h
runtime/mercury_table_type_body.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_tabling_preds.h:
runtime/mercury_term_size.c:
runtime/mercury_unify_compare_body.h:
Add the new builtin types and handle them throughout the runtime.
|
||
|
Zoltan Somogyi
|
30ec420984 |
Fix an anomaly in how in MLDS treats scalar commons.
compiler/mlds.m:
The MLDS used to have two different ways to refer to scalar common
data structures. It had an rval for the *name* of the scalar common,
and an mlds_name for its *address*. The name could then be wrapped up
inside a mlconst_data_adr function symbol to convert it to rval.
An mlds_name is intended to be used for the names of data definitions
in the MLDS, but scalar commons were never defined in this way.
And the name and address of a scalar common differ in C only by
the addition of an "&" operator in front, so the fact that they
had to be processed by different code (due to them having different types)
*required* double maintenance.
This diff fixes this anomaly by making both the name and the address
of a scalar common its own specific function symbol in the mlds_rval type.
They differ in the presence or absence of an "_addr" suffix.
Since all references to a vector common are to its address, give
the existing mlds_rval function symbol for vector commons the "_addr
suffix as well, for consistency.
Replace the general mlconst_data_addr function symbol in the
mlds_rval_const with its remaining instances. This allows the code
constructing them to be smaller and simpler, and enables them
to be treated differently in the future, if needed.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the changes in mlds.m.
Put the code translating the various common structures next to each other,
where they werent' before. Add XXXs about the differences between them
that are probably unnecessary and may possibly be latent problems.
compiler/ml_util.m:
Conform to the changes in mlds.m.
Change the interface to a set of predicates that looks for variables
inside various MLDS constructs to take a variable name, not a data name,
as the thing being looked for.
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_tailcall.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_target_util.m:
compiler/rtti_to_mlds.m:
Conform to the changes in mlds.m, and maybe ml_util.m.
In ml_proc_gen.m, put related arguments of some predicates and functions
next to each other.
|
||
|
Zoltan Somogyi
|
083f990dbb |
Simplify the use of contexts in the MLDS.
compiler/mlds.m:
This diff fixes two minor annoyances imposed by the old use of the
mlds_context type in the MLDS.
The first annoyance was that the mlds_context type used to be an
abstract type that was privately defined to be a trivial wrapper
around a prog_context. It had the exact same information content
as a prog_context, but you had to go through translation functions
to translate prog_contexts to mlds_contexts and vice versa.
I think Fergus's idea was that we may want to add other information
to the mlds_context type. However, since we haven't felt the need
to anything like that in the 18 years (almost to the day) that the
mlds_context type existed, I think this turned out to be a classic
case of YAGNI (you ain't gonna need it).
This diff deletes the mlds_context type, and replaces its uses
with prog_context.
The second annoyance was that actual MLDS code, i.e. values of the
mlds_stmt type, always had to wrapped up inside a term of the statement
type, a term which paired a context with the mlds_stmt.
This diff moves the context information (now prog_context, not
mlds_context) into each function symbol of the mlds_stmt type,
deletes the statement type, and replaces its uses with the now-expanded
mlds_stmt type. This simplifies most code that deals with MLDS code.
compiler/ml_util.m:
Add a function, get_mlds_stmt_context, for the (very rare) occasions
where we want to know the context of an mlds_stmt *before* testing
to see what function symbol it is bound to.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_simplify_switch.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tag_switch.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the changes above.
In some cases, a function was given two separate contexts, sometimes from
two separate sources; a prog_context and an mlds_context. In such cases,
keep only one source.
Standardize on Stmt as the variable name for "statement".
Delete redundant $module references from unexpected and other abort
predicates.
In one case, delete a function that was a duplicate of another function.
Give some predicates and functions more meaningful names.
|
||
|
Zoltan Somogyi
|
761de42e28 |
Tighten the type of flags in mlds_class_defns.
compiler/mlds.m:
As above.
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
91ba5278bc |
Tighten the type of flags in mlds_data_defns.
compiler/mlds.m:
As above.
compiler/ml_util.m:
Delete the predicate that returned the flags of *every* kind of definition
as a value of a single type.
Add a utility predicate used by both mlds_to_{cs,java}.m.
Delete utility predicates all of whose uses in the files below
this diff replaces with other code.
compiler/ml_closure_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the above.
In mlds_to_c.m, simplify some other related code.
|
||
|
Zoltan Somogyi
|
4c2a4eaa76 |
Eliminate most uses of mlds_entity_names.
compiler/mlds.m:
Change the target_code_entity_name target code component to
target_code_function_name, since we only ever put function names into it.
(Two pieces of code used to process data names and class names inside
target_code_entity_names, but these never had anything to process.)
compiler/ml_util.m:
Delete the defn_entity_name utility predicate, to force the recoding
of its call sites to test the kind of a *definition*, not the kind of
a *definition's name*.
Delete the defn_context utility predicate, since it isn't needed anymore.
Change tests for different kinds of definitions to return the specialized
(data, function or class) form of the definition, if relevant, to allow
the caller to use that form instead.
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the above, and avoid using mlds_entity_names in other ways
as well.
|
||
|
Zoltan Somogyi
|
63162fc7e3 |
Tighten the type of names in mlds_{function,class}_defns.
compiler/mlds.m:
Make type of the name of an mlds_function_defn not an mlds_entity_name,
but a bespoke type, mlds_function_name. To make this possible, create
the mlds_function_name type. This step also documents the fact that
the old entity_export names always applied to function definitions.
Make type of the name of an mlds_class_defn not an mlds_entity_name,
but a bespoke type, mlds_function_name. To make this possible, create
the mlds_type_name type. (The MLDS backend refers to mlds_class_defns
sometimes as "classes" and sometimes as "types"; when it handles
their names, it mostly uses the "type" terminology.)
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/mlds_to_target_util.m:
Conform to the above: stop wrapping and unwrapping data names.
In a few places, do some other cleanups.
|
||
|
Zoltan Somogyi
|
4738ccaef8 |
Create mlds_to_target_util.m.
compiler/mlds_to_target_util.m:
Create this new module to contain the common code that can be
factored out of mlds_to_{cs,java}.m, and (to a much lesser extent)
mlds_to_c.m.
In a few cases, give predicates better names, and/or generalize
their operation.
compiler/ml_backend.m:
compiler/notes/compiler_design.html:
Mention the new module.
compiler/ml_util.m:
Move some common code from mlds_to_{cs,java}.m to here (rather than
mlds_to_target_util.m) because it belongs with other procedures
that are already here.
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Delete the common code that has been factored out and moved to
the other modules.
To avoid ambiguity, in mlds_to_{cs,java.m}, add a "_for_java" or
"_for_csharp" suffix to the names of all the remaining types and
predicates that exist in both modules but with different definitions.
There were a lot of these, since mlds_to_cs.m was apparently created
by copy-and-paste from mlds_to_java.m.
|
||
|
Zoltan Somogyi
|
8f58542270 |
Tighten the type of names in mlds_data_defns.
compiler/mlds.m:
Make type of the name of an mlds_data_defn not an mlds_entity_name,
but an mlds_data_name, one of the several possibilities that
mlds_entity_name chooses amongst. For data definitions, we always
use a data name.
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the above: stop wrapping and unwrapping data names.
|
||
|
Zoltan Somogyi
|
869605956c |
Make MLDS definitions self-contained.
Until now, we used a single type, mlds_defn, to contain both
- generic information that we need for all MLDS definitions, such as
name and context, and
- information that is specific to each different kind of MLDS definition,
such as a variable's initializer or a function's list of parameter types.
The former were contained in three fields in the mlds_defns directly,
while the latter were contained in a fourth field that was a discriminated
union of mlds_data_defn, mlds_function_defn and mlds_class_defn.
While seemingly parsimonious, this design meant that if we had e.g. a list
of variable definitions, we would have to wrap the mlds_defn/4 wrapper around
them to give them their names, and thereafter, any code that processed
that list would have to be prepared to process not just variables but also
functions and classes.
This diff moves the three generic fields into each of the mlds_data_defn,
mlds_function_defn and mlds_class_defn types, making each those types
self-contained, and leaving mlds_defn as nothing more than a discriminated
union of those types.
In the few places that want to look at the generic fields *without*
caring about what kind of entity is being defined, this design requires
a bit of extra work compared to the old design, but in many other places,
the new design allows us to return mlds_data_defns, mlds_function_defns
or mlds_class_defns instead of just mlds_defns.
compiler/mlds.m:
Make the change described above.
Store type definions (for high level data) and table structures definitions
separately from other definitions in the MLDS type, since we can now
give them tighter types.
compiler/ml_global_data.m:
Change the fields that store flat cells from storing mlds_defns to
storing mlds_data_defns, since we can now do so.
Add an XXX about an obsolete comment.
compiler/mercury_compile_mlds_back_end.m:
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_string_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the changes above. Where possible with only local changes,
return mlds_data_defns mlds_function_defns or mlds_class_defns instead
of just mlds_defns. Put the mlds_data(_), mlds_function(_) or mlds_class(_)
wrapper around those definitions as late as possible (typically, when
our current code wants to put it into the same list as some other kind
of definition), in the hope that in the future, that wrapping can be
delayed even later, or even avoided altogether. Make the places where
such improvements may be possible with "XXX MLDS_DEFN".
In some places, the tighter data representation allows us to *delete*
"XXX MLDS_DEFN" markers.
Move some common code from mlds_to_{cs,java}.m to ml_util.m.
In mlds_to_{cs,java}.m, add prefixes to the function symbols in a type
to reduce ambiguity.
|
||
|
Zoltan Somogyi
|
1dba69825a |
Factor out the code for finding method ptrs.
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Both these modules used to have copies of about 250 lines of code
for finding method pointers in MLDS definitions. The two copies
were almost identical despite gathering their info in different types;
the only meaningful difference was in the small piece of code
that recorded the finding of a method pointer.
Delete these copies, and add code to compute the information each module
wants from the generalized data structure computed by the new common
code in ml_util.m.
compiler/ml_util.m:
Add the factored out common code in its generalized form.
|
||
|
Zoltan Somogyi
|
30c581b888 | Fix warnings from --warn-inconsistent-pred-order-clauses. | ||
|
Zoltan Somogyi
|
49fc26b6ff |
Store the mlds_defns of functions and data in their own types.
compiler/mlds.m:
The mlds_defn type can store the definition of a piece of data,
a function, or a class. The information contained in the definition
of a class was stored in a separate type, but the information stored
in the other two kinds of definitions weren't, which made it impossible
to store e.g. a list of just *data* definitions. Fix this by providing
two types that store the information contains in data and function
definitions respectively.
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_global_data.m:
compiler/ml_optimize.m:
compiler/ml_proc_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
compiler/rtti_to_mlds.m:
Conform to the change above.
|
||
|
Zoltan Somogyi
|
8dbea9f096 |
Use a structured representation for MLDS variables.
compiler/mlds.m:
Replace the old definition of mlds_var_name, which was a string
with an optional integer. The integer was intended to be the number
of a HLDS variable, while auxiliary variables created by the compiler,
which do not correspond to a HLDS variable, would not have the optional
integer.
This design has a couple of minor problems. The first is that there is
no place in the compiler where all the variable names are visible at once,
and without such a place, we cannot be sure that two names constructed
for different purposes don't accidentally end up with the same name.
The probability of such a clash used to be astronomically small
(which is why this hasn't been a problem), but it was not zero.
The second problem is that several kinds of compiler-created MLDS variables
want to have numerical suffixes too, usually with the suffix being a
unique sequence number used as a means of disambiguation. Most of the
places where these were created put the numerical suffix into the name
string itself, while some put the sequence number as the optional integer.
As it happens, neither of those actions is good when one wants to take
the independently generated MLDS code of several procedures in an SCC
and merge them into a single piece of MLDS code. For this, we want to
rename apart both the HLDS variable numbers and the sequence numbers.
Having the sequence number baked into the strings themselves obviously
makes such renumbering unnecessarily hard, while having sequence numbers
in the slots intended for HLDS variable numbers makes the job impossible
to do safely.
This diff switches to a new representation of mlds_var_names that
has a separate function symbol for each different "origin story"
that is possible for MLDS variables. This addresses both problems.
The single predicate that converts this structured representation
to a string is the place where we can ensure that two semantically
different MLDS variables never get translated to the same string.
The current version of this predicate does *not* offer this guarantee,
but later versions could.
And having all the integers used in mlds_var_names for different purposes
stored as arguments of different function symbols (that clearly indicate
their meaning) makes it possible to rename apart different sets
of MLDS variables easily and reliably.
Move the code for converting mlds_var_names from ml_code_util.m to here,
to make it easier to maintain it together with the mlds_var_name type.
compiler/ml_code_util.m:
Conform to the above change by generating structured MLDS var names.
Delete a predicate that is not needed with structured var names.
Delete the code moved to mlds.m.
Delete a predicate that has been unused since we deleted the IL backend.
Add ml_make_boxed_type as a version of ml_make_boxed_types that returns
exactly one type. This simplifies some code elsewhere.
Add "hld" to some predicate names to make clear that they are intended
for use only with --high-level-data.
compiler/ml_type_gen.m:
Conform to the above change by generating structured MLDS var names.
Add "hld" to the names of the (many) predicates here that are used
only with --high-level-data to make clear that fact.
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the above change by generating structured MLDS var names.
Add a "for_csharp" or "for_java" suffix to some predicate names
to avoid ambiguities.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_closure_gen.m:
compiler/ml_commit_gen.m:
compiler/ml_disj_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_foreign_proc_gen.m:
compiler/ml_gen_info.m:
compiler/ml_global_data.m:
compiler/ml_lookup_switch.m:
compiler/ml_optimize.m:
compiler/ml_string_switch.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
Conform to the above change by generating structured MLDS var names.
compiler/prog_type.m:
Add var_to_type, as a version of var_list_to_type_list that returns
exactly one type. This simplifies some code elsewhere.
compiler/java_names.m:
Give some predicates and functions better names.
compiler/ml_code_gen.m:
Fix typo.
|
||
|
Zoltan Somogyi
|
e5daa207fa |
Fix disabling warnings for non-tail recursive calls with MLDS.
compiler/mlds.m:
Add a field to call statements in MLDS that contains a (probably empty)
set of markers. At the moment, the only marker possible is one that says
"don't generate a non-tail recursive call warning for this call".
compiler/ml_gen_info.m:
Add a field to the ml_gen_info type, which contains the state of the
MLDS code generator, that records the set of warnings that are disabled
for the HLDS goal currently being translated.
compiler/ml_code_gen.m:
When processing the subgoal inside a disable_warnings scope,
add the warnings disabled by the scope to the new field
in the ml_gen_info.
compiler/ml_call_gen.m:
When creating MLDS call statements, put the new marker in the call's new
field if goal_warning_non_tail_recursive_calls is among the currently
disabled warnings.
compiler/ml_tailcall.m:
Don't generate warnings about a recursive call not being *tail* recursive
if the call has the new marker.
compiler/ml_accurate_gc.m:
compiler/ml_code_util.m:
compiler/ml_commit_gen.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_cs.m:
compiler/mlds_to_java.m:
Conform to the changes above.
|
||
|
Zoltan Somogyi
|
42ee3cbe39 |
Clarify the code that tests for tail recursive calls.
compiler/ml_optimize.m:
Move the call_optimize_tailcall predicate here, since it is called
only from this module. Give it a name that better describes its job,
and improve its documentation.
compiler/ml_util.m:
Give the call_is_recursive predicate a more precise (and non-leading)
name. Change its interface to avoid redundant tests in both this predicate
and its callers (of whether the MLDS statement is a call, and of whether
its callee is a constant code address), and also to avoid requiring
its callers to construct a module qualified name.
compiler/ml_tailcall.m:
Conform to the above changes.
|
||
|
Julien Fischer
|
092e175f45 |
Add a builtin unsigned word sized integer type -- Part 1.
Add a new builtin type: uint, which is an unsigned word sized integer type.
Support for this new type will need be bootstrapped over several changes.
This is the first such change and does the following:
- Extends the compiler to recognize 'uint' as a builtin type.
- Extends the set of builtin operations to include relational and (some)
arithmetic operations on uints.
- Extends all of the code generators to handle the above. There are some
limitations currently marked by 'XXX UINT'. These will be lifted once
the compiler recognised uint and additional library support becomes
available.
- Extends the runtime to support uints.
compiler/prog_type.m:
compiler/prog_data.m:
compiler/builtin_lib_types.m:
Recognize uint as a builtin type.
Add a new alternative to the cons_id/0 type corresponding to the uint type
-- for bootstrapping purposes its argument is currently an int.
compiler/builtin_ops.m:
Add builtin relational and arithmetic operations on uints. Note that the
existing 'unsigned_le' operation is actually intended for use with signed
values. Rather than attempt to modify its meaning, I have just added new
operations specific to the uint type.
compiler/hlds_data.m:
Add a new tag type for uints.
compiler/type_ctor_info.m:
Recognise uint as a builtin.
Bump the RTTI version number here.
compiler/ctgc.selector.m:
compiler/dead_proc_elim.m:
compiler/dependency_graph.m:
compiler/export.m:
compiler/foreign.m:
compiler/goal_util.m:
compiler/higher_order.m:
compiler/hlds_code_util.m:
compiler/hlds_out_pred.m:
compiler/hlds_out_util.m:
compiler/hlds_pred.m:
compiler/implementation_defined_literals.m:
compiler/inst_check.m:
compiler/mercury_to_mercury.m:
compiler/mode_util.m:
compiler/module_qual.qualify_items.m:
compiler/parse_tree_to_term.m:
compiler/parse_type_name.m:
compiler/polymorphism.m:
compiler/prog_out.m:
compiler/prog_rep.m:
compiler/prog_rep_tables.m:
compiler/prog_util.m:
compiler/rbmm.execution_path.m:
compiler/rtti.m:
compiler/special_pred.m:
compiler/switch_gen.m:
compiler/switch_util.m:
compiler/table_gen.m:
compiler/type_constraints.m:
compiler/type_util.m:
compiler/typecheck.m:
compiler/unify_gen.m:
compiler/unify_proc.m:
compiler/unused_imports.m:
compiler/write_module_interface_files.m:
compiler/xml_documentation.m:
Conform to the above changes to the parse tree and HLDS.
compiler/c_util.m:
Support generating builtin operations for uints.
compiler/llds.m:
Add a representation for uint constants to the LLDS.
Map uints onto MR_Unsigned.
compiler/call_gen.m:
compiler/dupproc.m:
compiler/exprn_aux.m:
compiler/global_data.m:
compiler/jumpopt.m:
compiler/llds_out_data.m:
compiler/llds_out_instr.m:
compiler/opt_debug.m:
compiler/opt_util.m:
Support uints in the LLDS code generator.
compiler/mlds.m:
Support uint constants in the MLDS.
compiler/ml_accurate_gc.m:
compiler/ml_call_gen.m:
compiler/ml_global_data.m:
compiler/ml_simplify_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/rtti_to_mlds.m:
Conform to the above change to the MLDS.
compiler/mlds_to_c.m:
compiler/mlds_to_java.m:
compiler/mlds_to_cs.m:
Generate the appropriate target code for uint constants and uint
relational operations.
compiler/bytecode.m:
compiler/bytecode_gen.m:
Handle uints in the bytecode generator: we just abort if we
encounter them for now.
compiler/elds.m:
compiler/elds_to_erlang.m:
compiler/erl_call_gen.m:
compiler/erl_code_util.m:
compiler/erl_rtti.m:
compiler/erl_unify_gen.m:
Handle uints in the Erlang code generator.
library/private_builtin.m:
Add placeholders for builtin_{unify,compare}_uint. Since the
bootstrapping compiler will not recognize uint as a type, we
give them polymorphic arguments. These can be replaced after
this change has bootstrapped.
Update the Java list of TypeCtorRep constants, which for some
reason is defined here.
library/uint.m:
New module that will eventually contain operations on uints.
library/MODULES_DOCS:
library/library.m:
Add the uint module.
library/construct.m:
library/erlang_rtti_implementation.m:
library/rtti_implementation.m:
mdbcomp/program_representation.m:
Handle uints.
deep_profiler/program_representation_utils.m:
Conform to the above change.
runtime/mercury_dotnet.cs.in:
Update the list of TypeCtorReps for C#
java/runtime/TypeCtorRep.java:
Update this, although the actual TypeCtorRep constants
are defined the library.
runtime/mercury_type_info.h:
Bump the RTTI version number.
Add an alternative for uints to the tyepctor rep enum.
runtime/mercury_builtin_types.{h,c}:
runtime/mercury_builtin_types_proc_layouts.h:
runtime/mercury_deconstruct.c:
runtime/mercury_deep_copy_body.h:
runtime/mercury_table_type_body.h:
runtime/mercury_tabling.h:
runtime/mercury_tabling_macros.h:
runtime/mercury_unify_compare_body.h:
Add uint as a builtin type and handle it throughout the runtime.
runtime/mercury_grade.h:
Bump the binary compatibility version.
runtime/mercury_term_size.c:
runtime/mercury_ml_expand_body.h:
Handle uint and fix probable bugs with the handling of ints on
64-bit Windows.
|
||
|
Paul Bone
|
c6cbc43448 |
Add new require_tail_recursion pragma.
This patch allows the pragma to be parsed, and records the information from
the pragma in the proc_info structure for the relevant procedures.
The patch uses the pragma for the MLDS backend. However because mutual
recursion is not yet supported on the MLDS backend, mutually recursive calls
are ignored by the pragma.
The patch also documents the pragma in the reference manual, this
documentation is commented out until it is implemented for both LLDS and
MLDS backends.
The patch does not implement the SCC feature discussed on the mailing list.
That can be added later.
compiler/prog_data.m:
compiler/prog_item.m:
Add new require_tail_recursion pragma.
compiler/prog_io_pragma.m:
Parse the new pragma.
Remove the arity_and_modes type and use pred_name_arity_mpf_mmode
type from prog_item.m
compiler/parse_tree_out_pragma.m:
Support pretty printing the new pragma.
compiler/hlds_pred.m:
Add require_tailrec_info to the proc_info structure.
compiler/add_pragma.m:
Add information from the pragma to the proc_info structure after
parsing.
compiler/compiler_util.m:
Add a general warning_or_error type.
compiler/mlds.m:
Add require_tailrec_info to MLDS functions.
compiler/ml_proc_gen.m:
Copy the require_tailrec_info information from the HLDS to the MLDS.
compiler/ml_tailcall.m:
Generate errors and warnings with respect to the require_tail_recursion
pragma.
compiler/mercury_compile.m:
compiler/mercury_compile_mlds_back_end.m:
Return errors from the MLDS tailcall optimisation pass.
compiler/add_pragma.m:
compiler/comp_unit_interface.m:
compiler/equiv_type.m:
compiler/get_dependencies.m:
compiler/item_util.m:
compiler/make_hlds_separate_items.m:
compiler/module_qual.qual_errors.m:
compiler/module_qual.qualify_items.m:
compiler/prog_item_stats.m:
compiler/recompilation.version.m:
compiler/write_module_interface_files.m:
Conform to changes in prog_item.m.
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.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 changes in mlds.m.
doc/reference_manual.texi
Document the require_tail_recursion pragma
tests/invalid/Mercury.options:
tests/invalid/Mmakefile:
tests/invalid/require_tail_recursion.err_exp:
tests/invalid/require_tail_recursion.m:
Add require_tail_recursion test case
|
||
|
Zoltan Somogyi
|
cc9912faa8 |
Don't import anything in packages.
Packages are modules whose only job is to serve as a container for submodules. Modules like top_level.m, hlds.m, parse_tree.m and ll_backend.m are packages in this (informal) sense. Besides the include_module declarations for their submodules, most of the packages in the compiler used to import some modules, mostly other packages whose component modules their submodules may need. For example, ll_backend.m used to import parse_tree.m. This meant that modules in the ll_backend package did not have to import parse_tree.m before importing modules in the parse_tree package. However, this had a price. When we add a new module to the parse_tree package, parse_tree.int would change, and this would require the recompilation of ALL the modules in the ll_backend package, even the ones that did NOT import ANY of the modules in the parse_tree package. This happened even at one remove. Pretty much all modules in every one of the backend have to import one or more modules in the hlds package, and they therefore have import hlds.m. Since hlds.m imported transform_hlds.m, any addition of a new middle pass to the transform_hlds package required the recompilation of all backend modules, even in the usual case of the two having nothing to do with each other. This diff removes all import_module declarations from the packages, and replaces them with import_module declarations in the modules that need them. This includes only a SUBSET of their child modules and of the non-child modules that import them. |
||
|
Paul Bone
|
086798fb24 |
Refactor the mlds non-tailcall warnings code
This refactoring ties this code directly to the tailcall detection code,
rather than as a pass of it's own. This makes it clearer that the warnings
match the actual tailcall detection.
I've posting this separately from my change to the behaviour of these
warnings to make it easier to see where I've deliberately changed Mercury's
behaviour.
compiler/ml_tailcall.m:
As above.
compiler/mercury_compile_mlds_back_end.m:
Conform to changes in ml_tailcall.m. Do not run a separate tailcall
warnings pass, this is now part of ml_mark_tailcalls/5.
compiler/ml_util.m:
Create a new predicate to test if a call is directly recursive. This
has been factored out of can_optimize_tailcall/2.
|
||
|
Zoltan Somogyi
|
c2473a20f3 | Delete unused imports. | ||
|
Julien Fischer
|
3dd02876a5 |
Delete the MLDS->IL backend.
compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
compiler/mlds_to_managed.m:
compiler/il_peephole.m:
compiler/ilasm.m:
compiler/ilds.m:
Delete the modules making up the MLDS->IL code generator.
compiler/globals.m:
compiler/prog_data.m:
Delete IL as a target and foreign language.
compiler/prog_io_pragma.m:
Delete the max_stack_size/1 foreign proc attribute. This was only
ever required by the IL backend.
compiler/options.m
Delete options used for the IL backend.
compiler/write_deps_file.m:
Don't generate mmake targets for .il files etc.
compiler/*.m:
Conform to the above changes.
compiler/notes/compiler_design.html
compiler/notes/work_in_progress.html
Conform to the above changes.
library/*.m:
Delete IL foreign_proc and foreign_export pragmas.
README.DotNet:
Delete this file.
browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
runtime/Mmakefile:
slice/Mmakefile:
Conform the above changes.
configure.ac:
Don't check that IL is a supported foreign language when performing the
up-to-date check.
Delete the '--enable-dotnet-grades' option.
scripts/Mmake.vars.in:
Delete variables used for the IL backend (and in on case by the Aditi
backend).
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
scripts/Mmake.rules:
scripts/canonical_grade.sh-subr:
tools/bootcheck:
Delete stuff related to the 'il' and 'ilc' grades.
doc/reference_manual.texi:
Delete the documentation of the 'max_stack_size' option.
doc/user_guide.texi:
Delete stuff related to the IL backend.
tests/hard_coded/csharp_test.{m,exp}:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/valid/csharp_hello.m:
Delete these tests: they are no longer relevant.
tests/hard_coded/equality_pred_which_requires_boxing.m:
tests/hard_coded/foreign_import_module.m:
tests/hard_coded/foreign_import_module_2.m:
tests/hard_coded/foreign_type.m:
tests/hard_coded/foreign_type2.m:
tests/hard_coded/foreign_type3.m:
tests/hard_coded/intermod_foreign_type2.m:
tests/hard_coded/lp.m:
tests/hard_coded/user_compare.m:
tests/invalid/foreign_type_2.m:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/invalid/foreign_type_visibility.m:
tests/invalid/illtyped_compare.{m,err_exp}:
tests/submodules/external_unification_pred.m
tests/valid/big_foreign_type.m
tests/valid/solver_type_bug.m
tests/valid_seq/foreign_type_spec.m
tests/valid_seq/intermod_impure2.m
Delete IL foreign_procs where necessary.
tests/hard_coded/Mmakefile
tests/invalid/Mercury.options
tests/invalid/Mmakefile
tests/submodules/Mmakefile
tests/valid/Mercury.options
tests/valid/Mmake.valid.common
tests/valid/Mmakefile
tests/valid_seq/Mmakefile
tests/valid_seq/Mercury.options
Conform to the above changes.
|
||
|
Zoltan Somogyi
|
7654ec847e | Convert (C->T;E) to (if C then T else E). |