Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confused about non-covered alternatives and RunPure #128

Open
Tiltedprogrammer opened this issue Dec 18, 2021 · 3 comments
Open

Confused about non-covered alternatives and RunPure #128

Tiltedprogrammer opened this issue Dec 18, 2021 · 3 comments

Comments

@Tiltedprogrammer
Copy link

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
Copy link
Member

I'll take a look.

@csabahruska
Copy link
Member

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
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants