[m-rev.] diff: fix --optimize-higher-order bug

[Fergus Henderson]

On 15-Jan-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> Estimated hours taken: 5
> Branches: main, release
> 
> compiler/higher_order.m:
> 	Fix a bug in `--optimize-higher-order' which caused compilation of 
> 	analysis/analysis.file.m to fail with inter-module optimization.
> 	The problem was that type-infos for curried arguments of a higher-order
> 	term were not being added to the typeinfo_varmap for the specialized
> 	procedure.

This change seems to have broken the hlc.agc grade.

The compiler now generates invalid C code for library/relation.m in grade
hlc.agc at -O3 or higher.  The generated C code refers to an undeclared
type_info variable.

The problem seems to be that the HLDS generated by higher_order.m is no
longer meeting an invariant which the accurate GC code is assuming.
In particular, the invariant that it assumes is this: for every
polymorphically typed variable which occurs in a procedure call,
the corresponding type_info variable for that type will also be
an argument of the procedure call.

The reason that this invariant is being broken is that the higher order
specialization pass is introducing a procedure that has *more than one
type_info argument corresponding to the same type variable*, and in the
body of the procedure there is a call which passes a variable of type
T, and a type_info that is a type_info for T, but the type_info passed
is not the type_info for T that was recorded in the type_info varmap.

Passing the same type_info multiple types is inefficient and is quite
likely to cause problems in later stages of the compiler.  So I think
higher_order.m should be modified to not pass the same type_info as
two separate arguments.

Simon, could you please fix this?

P.S.
Here's an extract from the final (stage 99) HLDS dump.

:- pred list:'UnusedArgs__pred__foldl__ho9__[1, 5, 6]_0'((private_builtin:type_info(T_1)), T_1, (private_builtin:type_info(T_1)), (list:list(T_1)), (relation:relation(T_1)), (relation:relation(T_1))).
% pred id: 1892, category: predicate, status: local
...
% type_info varmap:
% T_1 (number 1) -> type_info(TypeInfo_for_X_13)  (number 13)
...
:- mode 'UnusedArgs__pred__foldl__ho9__[1, 5, 6]_0'((ground -> ground), (ground -> ground), (builtin:in), (builtin:in), (builtin:in), (builtin:out)) is det.
list:'UnusedArgs__pred__foldl__ho9__[1, 5, 6]_0'(V_18, V_17, TypeInfo_for_X_13, HeadVar__2_2, HeadVar__3_3, HeadVar__4_4) :-
	...
			% context: file `relation.m', line 387
			% nonlocals: HeadVar__3_3, V_17, V_18, XKey_50, R1_51
			% determinism: det
			relation:add_element(V_18, HeadVar__3_3, V_17, XKey_50, R1_51)
			% pred id: 2, proc id: 0
			% new insts: XKey_50 -> ground
			%            R1_51 -> ground


Note how V_17 has type T_1, which is represented by TypeInfo_for_X_13,
but TypeInfo_for_X_13 is not passed to add_element.  This breaks the
invariant described above.  Instead, it passes V_18, which will have
the same value as TypeInfo_for_X_13, but which does not satisfy the invariant.

The same thing shows up in the HLDS dump immediately after the
higher-order pass.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------