[m-rev.] for review: fix equivalence type performance problems

Simon Taylor stayl at cs.mu.OZ.AU
Thu Dec 18 11:13:05 AEDT 2003


On 18-Dec-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 18-Dec-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > On 18-Dec-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 17-Dec-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > > On 12-Dec-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > > On 12-Dec-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > > > > compiler/mercury_compile.m:
> > > > > > 	Re-enable equiv_type_hlds.m.
> > > > > > 
> > > > > > tests/hard_coded/Mmakefile:
> > > > > > 	Re-enable testing of equiv_type_hlds.m.
> > > > > 
> > > > > I would like to see some performance figures for how much
> > > > > it costs to run this extra pass before we re-enable it.
> > > > 
> > > > With the extra change below, the equiv_type_hlds pass adds about
> > > > 5% to compile time, much of that in equiv_type.replace_in_type.
> > > 
> > > The extra changes below are fine.
> > > 
> > > I'd still rather avoid the extra 5% if we can...
> > > for the --high-level-data grades we can't, but is this pass
> > > really needed for the hlc and LLDS grades?
> > 
> > I'd say yes, because otherwise `:- pragma foreign_proc' and
> > `:- pragma export' will behave differently in different grades;
> > the foreign types of the arguments will be different.
> 
> Could we just expand equivalence types when converting Mercury types
> to foreign types?  In particular, in foreign__to_exported_type?

You wrote earlier:
> It's also needed by the MLDS->C back-end, for either --high-level-data,
> or for cases involving abstract equivalence types which are defined
> as "float".

So it is needed for hlc grades.
 
> We're already looking up the HLDS type definition there, to check for
> `foreign_type' declarations, so it wouldn't cost much more to check for
> equivalence types and expand them too.  I think that should cost a lot
> less than 5%.

But that's adding another level of complexity to the compiler
(equivalence types are sometimes fully expanded and sometimes
not).  The proper fix here is to change the representation of
types to something more efficient to work with.  That would save
more than 5%.

Simon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list