UPLC Code Gen Optimizations

[rvcas]

In no particular order

• functions that wrap builtins (like in stdlib) should be zero cost
• functions hoisted to needed scope by usage. Done in branch aiken_ir by the define_ir function.
• Binop reduction on Aiken-IR
• Inline var usage if used once after assignment #325
• vars being assigned to a lambda should just replace usages of that lam with the var name #326
• Better field access uplc function
• Advanced: BData vs Bytestring usage and IData vs Int usage to check if there is a need to unData the object
• Allow the extra validator params to be added at compile time thus allowing for inlining based on usage
• Allow when statements on multiple subjects. Disallowed
• Easy: inline builtins that use force and use the var for that builtin with force(s) pre-applied #324
• Fold and Reduce optimizations, maybe detect statically passed in vars and separate that from recurse part. Like cmp(). Add a compiler optimization for recursive functions #698
• Recursive functions can be optimized to reduce cost. Done in branch some_interesting_test_cases by the gen_uplc function.
• Group complex when clauses by first constructor to reduce comparison cost
• If using expect on a constr, list, tuple, if the fields are used later, reuse the ones from expect.
• Unused/Dead code handled by compile #323
• Multiple sort options and the ability to choose the best sort offchain and tell validator via redeemer
• Easy: Constr creation with constants should produce a constant like list does Added in Add assert. Refactor code to simplify code gen #245
• Single member constructors should use list. Needs serious discussions
• Forced wrapped builtins hoisted to there needed area by scope.
  

[micahkendall]

• vars (& consts) being assigned to a lambda should just replace usages of that lam with the var name
• Inline var usage if used once after assignment
• Easy: inline builtins that use force and use the var for that builtin with force(s) pre-applied
• Unused/Dead code handled by compile

I'm working on these as another pass over UPLC, not sure if it should be redone using Aiken IR or just added to the end of the compilation pipeline.

[nielstron]

For generic low level UPLC optimizations I can recommend checking out the pretty powerful optimizer build by @well-typed https://github.com/well-typed/plutonomy

Generally it is probably useful to have two optimization steps (as it is done usually in compilers):

1. at the level of aiken, using high-level knowledge
2. at the level of UPLC, using implementation details

Moreover consider options to disable optimizations (-O0, -O1) for debugging purposes.

[nielstron]

If you are writing a generic UPLC optimizer, I would like to invoke it as well in the build pipeline of eopsin so I am of course proposing to seperate the two steps suggested above by moving the UPLC optimizations into the UPLC crate.

[MicroProofs]

If you are writing a generic UPLC optimizer, I would like to invoke it as well in the build pipeline of eopsin so I am of course proposing to seperate the two steps suggested above by moving the UPLC optimizations into the UPLC crate.

I've added some uplc specific optimizations. I will add them to the cli later.

[MicroProofs]

Checking more off the list...