[jhc] Grin.

Lemmih lemmih at gmail.com
Sun Dec 7 06:02:31 EST 2008

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.


More information about the jhc mailing list