[m-rev.] for review: improve procname mangling for .NET backend.

[Fergus Henderson]

On 09-May-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 09-May-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 09-May-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > +	%	- Problem:
> > > +	%	  A semidet pred returns its success value, and so has
> > > +	%	  the same return type (bool) as a function.
> > > +	%
> > > +	%	  To avoid this, we mangle all semidet preds and
> > > +	%	  functions to include whether they are a pred or a
> > > +	%	  function using _p or _f.
> > 
> > The spec is not clear here: do you mean to mangle all functions
> > or just semidet functions?  The code below just mangles semidet
> > functions, but that's wrong, because the clash you're thinking of
> > here occurs when you have a det function and a semidet predicate, e.g.
> > 	
> > 	:- func foo(int) = bool
> > 	:- pred foo(int::in) is semidet.
> > 	% both map to `bool foo_1(int)'
> 
> I thought the code mangled semidet predicates *and* functions.

The code mangled semidet predicates and semidet functions.
It didn't mangle all functions.

> Which is more than it needs to do.

Right, mangling semidet predicates alone is enough.

> Actually, it might be fruitful to only add the _arity if the predicate
> has dummy arguments removed or type_info arguments added.   In all other
> cases it should be safe to leave the arity off. 
> But we should think about this one.

If you don't always add the arity, you lose the property that ensures
that there are no collisions with user-defined names.  So you'd need to
do something like always adding the arity if the predicate name ends in
something which might match one of the existing mangling schemes.

This would mean that the definition of whether or not to add _arity
would be quite complicated: the arity is added if the procedure
	(a) has any polymorphically typed arguments, or
	(b) has any arguments of type io__state or store__store(...), or
	(c) has a name that ends in [... some complicated pattern ..]

I think for our users it would be simpler if we just always add the arity.
It might be slightly uglier, but it is simpler and easier to use.

If we could get it so that the majority of procedures don't have
the arity appended, it might be worth it, but as long as we're adding
it to procedures with io__state arguments, I think we might as well
add it to all of them.

The only solution which avoids adding the arity mangling to
procedures with io__state arguments is the context-sensitive
solution: only mangle if a collision would occur.
That would be both easier for users and much less ugly.
But it's more work to implement.

> > However, there is another problem which you didn't mention.
> > The same thing can occur for predicates which are not semidet:
> > 	
> > 	:- func foo(int::out) = (int::in) is det.
> > 	:- pred foo(int::out, int::in) is det.
> > 	% both map to `void foo_2(int &, int)'
> > 
> > That needs to be fixed.
> 
> Ok, so non-default mode funcs should be mangled with _f.

That would solve it (but see below).  Another possible solution is to
mangle all predicates with _p.  I'm not sure which of these is worse.

> > I think that it may be possible to have conflicts with user names
> > in the case where there is a <modulename>.  However, this is a minor
> > issue; it's probably OK to just XXX it for now.

To elaborate on that: the <modulename> here is (I think) the module that
declared this procedure, if it was different from the module which is
defining the procedure.  This can only occur in cases of intermodule
optimization.  In those cases, where we generate code for an inlined,
specialized, or otherwise optimized version of a predicate that was
declared in a different module, the optimized version will be local
to the module in which it is generated.  The case where there is an
extra <modulename> to mangle can't (or at least shouldn't) occur for
publically visible procedures.  So it's not an ABI issue.

> Here's an incremental diff that addresses these problems.
> 
> --- zzlog.mangling2	Wed May  9 01:50:03 2001
> +++ zzlog.mangling4	Wed May  9 23:22:36 2001
> @@ -10,11 +10,12 @@
>  compiler/mlds.m:
>  compiler/mlds_to_c.m:
>  compiler/mlds_to_java.m:
> -	Add the code_model to the proc_label.
> +	Add the code_model and a boolean indicating whether this
> +	function has a non-default (in, in, in, out) mode to the proc_label.

I think that's not the best test to use.  I think the test that should be
used to decide whether to add extra mangling should be the same one
that is used to decide whether to make the Mercury function result an
MLDS function return value (rather than an MLDS function argument),
i.e. `is_output_det_function' in ml_code_gen.m.  See the comments for
is_output_det_function for more details.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  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
--------------------------------------------------------------------------