[m-rev.] for review: IL back-end: use value types for environments

[Fergus Henderson]

On 17-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 17-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 15-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 14-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > On 14-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > > 
> > > > > For the IL back-end, use value types rather than class types
> > > > > for the environment structures used for nondeterministic code.
> > > > 
> > > > This doesn't work, because you can't use `refany' types as fields of structures.
> > > > 
> > > > We had the same problem with ordinary managed reference types, and worked around
> > > > that by putting a value rather than a reference in the environment struct,
> > > > and using copy-in copy-out.
> > > > 
> > > > But that work-around won't help here, since there's no generic type we can use
> > > > for the value.
> > > > 
> > > > :-(
> > > 
> > > Plan B is to use unmanaged pointers rather than 'refany'.
> > > 
> > > (Still not 100% sure if this plan is feasible,
> > > since I haven't implemented it yet.)
> > 
> > I've implemented it, and it works.
> > 
> > > This will of course be completely unverifiable.
> > > So it ought to be optional, with the other option being to
> > > allocate nondet environments on the heap (as we do currently).
> > 
> > I plan to implement that compiler switch in the long run.
> > But I think it might be best to just check in this change as is for now.
> > 
> > Comments?
> 
> I don't know whether it's a good idea to make the code less verifiable
> than it already is.  Particularly if you can't even switch it on or off.
> 
> Does this code achieve anything at all apart from moving the goalposts
> of verifiable code further away? 

Yes, it improves efficiency.

> If you are going to say efficiency, I'm going to say there are *lots* of
> other things we could work on that are fully verifiable that could give
> us better efficiency.

Such as?
The only ones that I know of are fixing `--high-level-data' (not sure
exactly what is required there) and eliminating temporary variables.

> (I'd have no problem with this code if it were switchable, or if you
> cleaned up the code for doing heap allocated environments at the same
> time).

Well, I do plan to make it switchable eventually.
The question is just whether to commit this now,
or to wait until I've made it switchable.

I don't mind much either way.

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