[m-dev.] compare for existential types failing

[Zoltan Somogyi]

On 08-Nov-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> The symptom in the first few that I looked at is an internal error in
> the code generator while generating code for the comparison predicate
> for an existentially quantified data type.
> 
> My guess is that the problem is probably due to Zoltan's recent
> changes to comparison predicates, and that the compiler may be
> emitting bad HLDS annotations which cause the code generator to abort.

My investigation shows that this symptom is the consequence of two
separate bugs, neither concerned with my recent change.

The first bug is that when simplify.m removes an assignment such as

	TypeClassInfo_for_v_8 = V_17
	
by replacing TypeClassInfo_for_v_8 with V_17 throughout the procedure body,
it does not perform the replacement on the proc_type_info_varmap and
proc_typeclass_info_varmap fields of the procedure. This is the direct
cause of the symptom: trace.m looks up the type of a variable that is live at a
switch event, finds that it contains a type variable (T_1) whose typeinfo is
stored in TypeClassInfo_for_v_8, and dies because that variable was deleted
by simplification.

The second bug is that when cse_detection.m replaces

	(
		HeadVar__2_2 = x:u(TypeClassInfo_for_v_8, V_4),
		...
	;
		HeadVar__2_2 = x:u(TypeClassInfo_for_v_14, V_6)
		...
	)

with

	HeadVar__2_2 = x:u(V_17, V_16)
	(
		TypeClassInfo_for_v_8 = V_17,
		V_4 = V_16,
		...
	;
		TypeClassInfo_for_v_14 = V_17,
		V_6 = V_16,
		...
	)

it neglects to update several fields of the proc_info; the following extract
from the HLDS dump is currently the same before and after cse.

% type_info varmap:
% T_1 (number 1) -> typeclass_info(TypeClassInfo_for_v_8, 1)
% T_3 (number 3) -> typeclass_info(TypeClassInfo_for_v_14, 1)
% typeclass_info varmap:
% x:v(T_1) -> TypeClassInfo_for_v_8
% x:v(T_3) -> TypeClassInfo_for_v_14
% head_type_params:
% T_3, T_1
% variable types map:
% V_4 (number 4) :: T_1
% V_6 (number 6) :: T_3

Cse should have updated this to read:

% type_info varmap:
% T_1 (number 1) -> typeclass_info(V_17, 1)
% typeclass_info varmap:
% x:v(T_1) -> V_17
% head_type_params:
% T_1
% variable types map:
% V_4 (number 4) :: T_1
% V_6 (number 6) :: T_1

Both bugs are understandable, since existentially typed data structures
did not exist when they were written.

I will sit down with DJ and fix cse_detection friday morning or next week
(I have 252 exams tomorrow and friday afternoon). In the meantime, I have set
the default value of --compare-specialization back to 1 as a workaround.

Actually, I think simplify.m may be correct after all, though not robust.
After the fix to cse_detection.m, I can't think of any situation in which
simplify should be able to eliminate typeinfo or typeclassinfo variables.
Can anyone else?

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------