lhmouse/asteria

Merge name lookups with in a whole expression

Closed this issue · 7 comments

For example in x * x + y * y. This is possible because expressions can't introduce new names.

This is a dedup, but not a merge.

Make let an expression and use ANF.

This very simple expression compiles to x x * y y * + in RPN, which is

                              # stack:
push_local_reference "x"      # (x)
push_local_reference "x"      # (x) (x)
apply_operator xop_mul        # (x*x)
push_local_reference "y"      # (x*x) (y)
push_local_reference "y"      # (x*x) (y) (y)
apply_operator xop_mul        # (x*x) (y*y)
apply_operator xop_add        # (x*x+y*y)

The stack is left with one reference to a temporary, which is the sum of the final addition.
If this is a full expression, it is not necessary to remove extra references beneath the result, so this can be transformed to

                              # stack:
push_local_reference "x"      # (x)
push_local_reference "y"      # (x) (y)
push_back_reference -1        # (x) (y) (x)
push_back_reference -2        # (x) (y) (x) (x)
apply_operator xop_mul        # (x) (y) (x*x)
push_back_reference -1        # (x) (y) (x*x) (y)
push_back_reference -2        # (x) (y) (x*x) (y) (y)
apply_operator xop_mul        # (x) (y) (x*x) (y*y)
apply_operator xop_add        # (x) (y) (x*x+y*y)

I made a simple test and it turned out to run slower. I am putting this on suspension for now.

std::any/std::unique_ptr = performance bug, definitely you have performance issues

WTF are you mumbling about?

Closing this, because profiling (with RDTSC) discovered that name lookups and copy ctors of Reference are on a par.

Given the suggested optimization is a non-trivial and important kind, I don't think there are sufficient reasons to close the issue. This should be reflect in the plan of improvement of the optimizations (if any).

Yeah you can reopen it.