[m-rev.] for review: reasons not to delete procs in dead_proc_elim.m

[Zoltan Somogyi]

2022-05-13 17:09 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> +                % Don't eliminate unify or compare predicates, because we
>> +                % won't identify calls to them until after polymorphism.
> 
> I know this is an existing comment, but what's it mean.  Dead procedure
> elimination is not run until well after the polymorphism pass anyway --
> is "polymorphism" a reference to the pass of the same name?
> (Actually, you presuambly cannot delete them unless you can prove that
> the types they belong to are unused and/or that they are not going to
> be called through RTTI.)

You are right, that comment was both ancient and wrong, though
when dead proc elimination is run was irrelevant to this, as it was
part of dead PRED elimination, which is run much earlier.

I replaced it with this:

% Don't eliminate unify or compare predicates, for two reasons.
%   
% First, because higher_order.m may introduce calls to them
% when it specializes calls to builtin.unify or builtin.compare
% respectively in situations when it knows the types of the 
% values to be unified or compared. Until that pass has been
% run, we don't know which otherwise-dead unify or compare
% predicates it will "bring back to life".
%   
% Second, we don't want to delete even a never-called
% unification or compare predicate while that predicate
% has a pointer to it from its type_ctor's type_ctor_info
% structure, and until this writing (2022 may 13), dead
% procedure elimination has never had code to eliminate
% unused type_ctor_info structures. The reason for that is
%   
% - many places can refer to type_ctor_infos, so proving that
%   one is unused requires significant programming effort, but 
%   
% - virtually all type_ctor_infos that get created are actually
%   used, so that effort, and the time required to run the 
%   resulting code, would be wasted in the vast majority of
%   compilations.

You may want to look at the attached diff to higher_order.m,
which also gives it its own bespoke option to replace -V.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.ho
Type: application/octet-stream
Size: 613 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220513/a170218c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.ho
Type: application/octet-stream
Size: 12630 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220513/a170218c/attachment-0001.obj>