mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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>
This commit is contained in:
Vincent Ambo 2023-01-29 23:40:57 +03:00 • committed by tazjin
parent f2afd38f2d
commit 32698766ef
3 changed files with 94 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

14
tvix/eval/docs/known-optimisation-potential.md
View file

@ -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]