only push temporaries that can be live at a gc checkpoint

[mascarenhas]

I based this PR on top of the records one, so it should be merged only after that one, as both are pretty invasive on the code generator.

This PR implements an optimization where we try to push GC-able temporaries only prior to intra-statement function calls (a possible GC point). The other GC points that we have, loops, do not count, as by definition temporaries are not live across statements. I am pretty confident that I have covered all possible bases so we will not have any dangling pointers, but of course I have not formally proven that the optimization is sound. 😈

This should really cut into the stack usage of code that uses complex expressions. The next step is to do liveness analysis on local variables, so a similar optimization can be done for them too, but this can go in another PR.

By the way, I recall that the Lua test suite compiles Lua with some flag where the GC is very aggressive so dangling pointers surface more easily, I think we should do something similar in our test suite so we can have effective GC tests.

[codecov-io]

Codecov Report

Merging #217 into master will increase coverage by 0.13%. The diff coverage is 89.62%.

Impacted Files	Coverage Δ
titan-compiler/coder.lua	96.01% <89.62%> (-0.34%)	:arrow_down:
titan-compiler/util.lua	61.81% <0%> (-7.28%)	:arrow_down:
titan-compiler/checker.lua	90.12% <0%> (+0.61%)	:arrow_up:
titan-compiler/driver.lua	63.08% <0%> (+3.51%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update bfd59ac...7036403. Read the comment docs.

[mascarenhas]

This branch got really broken, as it should just have the last two commits instead of duplicates of all the record-related commits. @hishamhm, I have no intention to merge this for the time being, but it is a good idea to fix it so I can keep it tracking the master branch.

[hishamhm]

@mascarenhas Rebased the PR!

[mascarenhas]

Thanks @hishamhm!

[mascarenhas]

I really need to make a habit of using git rebase -i instead of just rebase, would have saved me an hour of headaches when updating this branch.

[mascarenhas]

If it gets too troublesome to keep making this track master I will just drop this, we can do this optimization properly once we have a language that is actually useful and pleasant to program in so we will have time to focus solely on improving the code generator.

[hishamhm]

git rebase -i is indeed your best friend when doing rebases!

Other tips:

• when experimenting, create another branch and mess with it until happy. you can use git cherry-pick to pick commits one by one (or replace one branch with another entirely with git reset --hard (careful!))
• when things get out of hand, and you realize you're probably making a mess during the rebase, use git rebase --abort to start over.
• gitk really helps visualizing how things are laid out, and navigating history — a very underrated tool
• if you did something you regret, git reflog allows you to go back to any previous state of your git tree, and git reset --hard (careful! :) ) reverts a branch to those commits. This is the real "undo" in git.

[mascarenhas]

Thanks for the tips. This tool looks very interesting, is free for open source projects, and seems easy to write Lua backend, but the current version if Windows-only (they are working on Linux/OSX versions, though).