[jhc] Grin.

[John Meacham]

On Sun, Dec 07, 2008 at 12:02:31PM +0100, Lemmih wrote:
> > No, it only falls back to indirect evaluation when the standard grin
> > transformation would have not been able to improve matters much, as in,
> > when it would have ended up a large cache-killing case scrutininization
> > anyway. Many cases can be directly transformed into loops just like the
> > original Grin paper. The idea was to turn the points-to analysis from a
> > fundamental method of correctness into a powerful optimization
> > primitive. (but not strictly necessary for compilation). I went through
> > several iterations of 'points-to' analysis as the jhc internals evolved.
> > This continual retooling of the analysis was something I was hoping to
> > avoid in the future by allowed the indirect fallback.
> 
> >From looking at Grin.EvalInline, it would seem the code has been
> disabled. The grin output of 'sum' example backs this up as 'eval' is
> never inlined.

It is entirely likely I disabled it while debugging another part of the
code for fault isolation. The new runtime was designed to support more
of an 'compilation by transformation' sort of style of development.
Accepting higher level calls to eval as well as direct inlined code. I
believe I last had it set to use 'eval' in all cases except when it can
be proved there was only a single code path, in which case it should
call that function directly (or perform the loop directly). But I don't
recall exactly, I was working on front end type system issues so
switched off all the transformations that wern't 100% reliable. 

-- 
John Meacham - ⑆repetae.net⑆john⑈