Mark all GC functions as yk_outline.
#131
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are few, if any, GC functions that we want to trace directly but at the moment, SWT inserts tracing blocks which (a) slows these functions down in all cases (b) particularly slows them down if tracing is active. At first I started going through these individually, seeing which end up being outlined before realising that really what I want to do is say "all of the functions in this file should be outlined". I don't believe there's a way to attach such an attribute to a file in LLVM -- or, at least, we don't have the right hooks for it in ykllvm right now -- so this commit simply marks every function in this file as `yk_outline`. It wouldn't surprise me if, in the future, we come back and unmark one or two functions, but I doubt we'll need or want to do that soon. Across our benchmark suite this leads to a sizeable performance increase, with many benchmarks improving by around 8-9%.
ltratt
added a commit
to ltratt/yklua
that referenced
this pull request
Dec 13, 2025
In ykjit#131 I added `yk_outline` to nearly every GC function and got an 8-9% speedup. Much has changed since then in how we optimise programs, so I decided to revisit this. First, as I noted in ykjit#131, I was sloppy and added `yk_outline` to functions with loops in (i.e. those that could never be inlined). Those are easily removed. Indeed, _most_ of the static functions in this file can't be reached (even indirectly) from the outside world, so most of those can also have `yk_outline` removed. Really what we have to think about are the `luaC_*` functions. A quick bit of experimentation suggests that, at least for now, they're best left outlined. Overall, this commit has no meaningful performance change that I can measure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are few, if any, GC functions that we want to trace directly but at the moment, SWT inserts tracing blocks which (a) slows these functions down in all cases (b) particularly slows them down if tracing is active.
At first I started going through these individually, seeing which end up being outlined before realising that really what I want to do is say "all of the functions in this file should be outlined". I don't believe there's a way to attach such an attribute to a file in LLVM -- or, at least, we don't have the right hooks for it in ykllvm right now -- so this commit simply marks every function in this file as
yk_outline. It wouldn't surprise me if, in the future, we come back and unmark one or two functions, but I doubt we'll need or want to do that soon.Across our benchmark suite this leads to a sizeable performance increase, with many benchmarks improving by around 8-9%.