[m-dev.] for review: compiler-generated procedures

[Fergus Henderson]

On 30-Sep-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> The code we were creating for the comparison procedure of an enumerated type
> called mercury__compare_3_3, which called the comparison procedure of the
> enumerated type (whose address was in the compare slot of the type_ctor_info).
> This was an infinite loop. I think it only used to work because higher-order
> specialization specialized the call to mercury__compare_3_3, but specialization
> is turned off for debugging.

That specialization used to be done unconditionally in polymorphism.m.
But Simon recently changed that.  So that is why this has shown up now.

> compiler/unify_proc.m:
> 	Fix the generation of the compare procedures for enumerated types;
> 	instead of calling mercury__compare_3_3, we cast the args to ints
> 	and call builtin_compare_int.

You fixed the problem for compare, but won't the same problem arise
for index and unify?

> +++ unify_proc.m	1999/09/30 07:41:10
> @@ -502,7 +502,8 @@
>  	is det.
>  
>  unify_proc__generate_unify_clauses(TypeBody, H1, H2, Context, Clauses) -->
> -	( { TypeBody = du_type(Ctors, _, IsEnum, MaybeEqPred), IsEnum = no } ->
> +	(
> +		{ TypeBody = du_type(Ctors, _, IsEnum, MaybeEqPred) },
>  		( { MaybeEqPred = yes(PredName) } ->
>  			%
>  			% Just generate a call to the specified predicate,
> @@ -521,15 +522,31 @@
>  			{ Goal = Call - GoalInfo },
>  			unify_proc__quantify_clause_body([H1, H2], Goal,
>  				Context, Clauses)
> -		;
> -			unify_proc__generate_du_unify_clauses(Ctors, H1, H2,
> +		; { IsEnum = yes } ->
> +			{ create_atomic_unification(H1, var(H2), Context,
> +				explicit, [], Goal) },
> +			unify_proc__quantify_clause_body([H1, H2], Goal,
>  				Context, Clauses)

See comment above: won't that suffer from the same infinite recursion problem
that you are trying to fix?

> +		;
> +			unify_proc__generate_du_unify_clauses(Ctors,
> +				H1, H2, Context, Clauses)
>  		)
> +
>  	;
> +		{ TypeBody = eqv_type(_Type) },
> +		% We should check whether _Type is abstract or not.
> +		% If it is, we should call its unification procedure;
> +		% if it is not, we should generate its body inline here.

Is there any particular reason to do that specialization here,
rather than just relying on the compiler's usual specialization
optimizations to do it?

The comment here misses the cases where `_Type' is a polymorphic type
variable.  This can arise from `:- type foo(T) == T'.

>  unify_proc__generate_index_clauses(TypeBody, X, Index, Context, Clauses) -->
> -	( { TypeBody = du_type(Ctors, _, IsEnum, MaybeEqPred), IsEnum = no } ->
> +	(
> +		{ TypeBody = du_type(Ctors, _, IsEnum, MaybeEqPred) },
>  		( { MaybeEqPred = yes(_) } ->
>  			%
>  			% For non-canonical types, we just give up and
> @@ -551,15 +569,30 @@
>  				ArgVars, Context, Goal),
>  			unify_proc__quantify_clause_body(ArgVars, Goal,
>  				Context, Clauses)
> +		; { IsEnum = yes } ->
> +			{ ArgVars = [X, Index] },
> +			unify_proc__build_call(
> +				"index", ArgVars, Context, Goal),
> +			unify_proc__quantify_clause_body(ArgVars, Goal,
> +				Context, Clauses)

See comment above: won't that suffer from the same infinite recursion problem
that you are trying to fix?

>  		;
>  			unify_proc__generate_du_index_clauses(Ctors, X, Index,
>  				Context, 0, Clauses)
>  		)
>  	;
> +		{ TypeBody = eqv_type(_Type) },
> +		% XXX zs: I believe this code works only by accident.
> +		% XXX the point for unify also applies here
>  		{ ArgVars = [X, Index] },
>  		unify_proc__build_call("index", ArgVars, Context, Goal),
>  		unify_proc__quantify_clause_body(ArgVars, Goal, Context,
>  			Clauses)

I don't think you're right about it only working by accident.
There's quite a bit of code which goes to some trouble to ensure
that the type used in the body of the unification/compare/index
predicates for an equivalence type is the expanded type,
even though the types used for the interface are the unexpanded type.

> +			{ construct_type(unqualified("int") - 0, [],
> +				IntType) },

Better to use the int_type/0 function in type_util.m.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------