[jhc] Grin.

[Lemmih]

On Sun, Dec 7, 2008 at 11:52 AM, John Meacham <john at repetae.net> wrote:
> On Sun, Dec 07, 2008 at 11:43:58AM +0100, Lemmih wrote:
>> What about the missed optimization opportunities? In the GRIN paper,
>> Boquist shows how 'foldl (+) 0 [1..n]' could be compiled to a strict
>> loop with no allocations. Without points-to analysis (which seems to
>> be completely disable at this point) most of the important
>> optimizations are blocked and the resulting program is far less
>> efficient than it should be.
>
> 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.

-- 
Cheers,
  Lemmih