Higher order codegen

[NeuralCoder3]

This branch contains fixes for higher-order code generation. The fixes regard the llvm backend, memory dialect, and closure conversion dialect.

This branch is the base of the current state of automatic differentiation and the matrix dialect.

Summary

Miscellaneous:

• .gitignore: ignore build folder but not everything with build in its name
• error.sh: small script to make it easier to provide issue information for failing tests

Core

• dump filters for functions
• print list of executed passes
• fix lam_spec divergence

Dialects

• refly:
  • debug_dump: a pass that just dumps the world to stdout
• affine:
  • correctly propagate accumulator
• compile/opt:
  • move dialect conditionals from opt to compile for accessibility
  • generalize internal cleanup phase to avoid code duplication (parametrized over prefix)
• direct
  • fix issue of nested cps2ds calls using a stack
• mem
  • more mem manipulation operations (not assuming mem at position 1)
  • reshape: rewrite argument shape of a function (take special care of mems)
  • add_mem: documentation improvement, ignore argument position mems
• core:
  • add free
• clos:
  • move phase2pass wrapper

Tests

• allow filter annotation in printed thorin code
• more direct, mem, clos tests regarding mem issues

[leissa]

On a more stylistic note, I think we should remove the space just in front of the @ when dumping filters. Say, we have a curried function:

.con foo(a: T)@(.tt)(b: U) = /*...*/

With the current logic, it would look like this:

.con foo(a: T) @(.tt)(b: U) = /*...*/

And now it looks as if the filter belongs to the second curried function.

[NeuralCoder3]

On a more stylistic note, I think we should remove the space just in front of the @ when dumping filters. Say, we have a curried function:

.con foo(a: T)@(.tt)(b: U) = /*...*/

With the current logic, it would look like this:

.con foo(a: T) @(.tt)(b: U) = /*...*/

And now it looks as if the filter belongs to the second curried function.

Do curried functions still exist at the dumping stage? I would expect them to be syntactic sugar that is resolved at parsing.

[leissa]

On a more stylistic note, I think we should remove the space just in front of the @ when dumping filters. Say, we have a curried function:

.con foo(a: T)@(.tt)(b: U) = /*...*/

With the current logic, it would look like this:

.con foo(a: T) @(.tt)(b: U) = /*...*/

And now it looks as if the filter belongs to the second curried function.

Do curried functions still exist at the dumping stage? I would expect them to be syntactic sugar that is resolved at parsing.

correct. But I still find it better for the sake of consistency to remove the space.