refactor(tvix/eval): statically resolve select from constant attrs r/5831

When resolving a select expression (`attrs.name` or `attrs.name or
default`), if the set compiles to a constant attribute set (as is most
notably the case with `builtins`) we can backtrack and replace that
attribute set directly with the compiled value.

For something like `builtins.length`, this will directly emit an
`OpConstant` that leaves the `length` builtin on the stack.

Change-Id: I639654e065a06e8cfcbcacb528c6da7ec9e513ee
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7957
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>

1 files changed, 4 insertions, 10 deletions

diff --git a/tvix/eval/docs/known-optimisation-potential.md b/tvix/eval/docs/known-optimisation-potential.md
index df13577de3..f45f1ee6c4 100644
--- a/tvix/eval/docs/known-optimisation-potential.md
+++ b/tvix/eval/docs/known-optimisation-potential.md
@@ -50,17 +50,11 @@ optimisations, but note the most important ones here.
   can directly use the `value::function::Lambda` representation where
   possible.
 
-* Optimise inner builtin access [medium]
+* Apply `compiler::optimise_select` to other set operations [medium]
 
-  When accessing identifiers like `builtins.foo`, the compiler should
-  not go through the trouble of setting up the attribute set on the
-  stack and accessing `foo` from it if it knows that the scope for
-  `builtins` is unshadowed. The same optimisation can also be done
-  for the other set operations like `builtins ? foo` and
-  `builtins.foo or alternative-implementation`.
-
-  The same thing goes for resolving `with builtins;`, which should
-  definitely resolve statically.
+  In addition to selects, statically known attribute resolution could
+  also be used for things like `?` or `with`. The latter might be a
+  little more complicated but is worth investigating.
 
 * Inline fully applied builtins with equivalent operators [medium]