grin-compiler / grin

GRIN is a compiler back-end for lazy and strict functional languages with whole program optimization support.
https://grin-compiler.github.io/
1.03k stars 38 forks source link

Confused about non-covered alternatives and RunPure #128

Open Tiltedprogrammer opened 2 years ago

Tiltedprogrammer commented 2 years ago

Hi!

I've made a simple frontend for GRIN and struggle with the optimizations.

  1. When running stack exec grin -- --optimize --no-prelude --print-errors --continue-on-failed-lint dump.grin for this I get a lot of

case has non-covered alternative CError
case has non-covered alternative CFalse
case has non-covered alternative CNode
case has non-covered alternative CNone
case has non-covered alternative CTrue
case has non-covered alternative CVal
....

which fails the linting and I guess it is the result of eval inlining and case alternatives removal, but I don't know why linting should fail then. And finally, I get my process killed on RunPure stage:


PHASE #3
  PipelineStep: T BindNormalisation                                                           had effect: None (0.001100 ms)
  PipelineStep: T SimpleDeadVariableElimination                                               
  Analysis
   PipelineStep: Eff CalcEffectMap                                                            (0.000600 ms)
  had effect: None (1.962300 ms)
  PipelineStep: T NonSharedElimination                                                        
  Analysis
   PipelineStep: Sharing Compile                                                              (0.000800 ms)
   PipelineStep: Sharing RunPure                                                              iterations: Killed
  1. When running stack exec grin -- --optimize --no-prelude --print-errors --continue-on-failed-lint dump_2.grin for this I get the same but the process gets killed on hpt stage:

PipelineStep: T SparseCaseOptimisation                                                      had effect: None (0.696800 ms)
  PipelineStep: T CaseHoisting                                                                had effect: None (0.945100 ms)
  PipelineStep: T GeneralizedUnboxing                                                         had effect: None (0.008400 ms)
  PipelineStep: T ArityRaising                                                                had effect: None (0.040300 ms)
  PipelineStep: T InlineApply                                                                 had effect: None (1.803600 ms)
  PipelineStep: T LateInlining                                                                Invalidating type environment
  had effect: ExpChanged (12.713100 ms)
  PipelineStep: SaveGrin (Rel "LateInlining.grin")                                            (13.689900 ms)
  PipelineStep: T BindNormalisation                                                           had effect: ExpChanged (0.001200 ms)
  PipelineStep: SaveGrin (Rel "BindNormalisation.grin")                                       (23.816600 ms)
  PipelineStep: T InlineEval                                                                  
  Analysis
   PipelineStep: HPT Compile                                                                  (0.000400 ms)
   PipelineStep: HPT RunPure                                                                  iterations: 144 Killed

and sometimes I also have some type env errors after HPT.

So the question is whether it is supposed to be like this and are there a set of transformations/optimizations/workarounds that are guaranteed to proceed successfully and output simple enough GRIN to compile it into hardware?

P.S. both examples work fine in --eval

csabahruska commented 2 years ago

I'll take a look.

csabahruska commented 2 years ago

It seems that the current dataflow machinery in the current grin implementation is inefficient. That's why we switched to Souffle Datalog to fix this issue. I use Souffle Datalog in external stg and its corresponding analyses, however we have not integrated it to the grin implementation yet. Until that happens grin can only analyse tiny programs. Souffle could handle this input in few milliseconds.

Tiltedprogrammer commented 2 years ago

Is there any relatively painless and seamless way to make these programs proceed grin pipeline? Maybe I can switch back and forth to stg to use souffle?