Update CodeGen to enable the Luau::CodeGen::CodeGen_ColdFunctions flag, and set up random number generators for NCG.#61
Merged
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We got a bug report about IR and assembly generation failing sometimes. The circumstances for when this happen seem to be when the top-level function gets marked cold. We have a flag that we use in the
luauCLI to avoid this issue, and we can set up the same flag to avoid the issue here. There's actually a secondary issue where, at the least, arm64 generation relies onoffsetofextensively and we're currently building for wasm32, causing the offset math to not line up and the codegen to error out.An example program demonstrating this bug:
It's a bit funny to learn that NCG relies on the host platform being 64-bit, but it's a non-trivial problem to work around. The easiest solution would be to enable wasm64, where the offsets will once again match up with our native architectures. Unfortunately, wasm64 is not supported in Safari as of the time of writing, and a significant portion of our Playground users are on Safari. An alternative solution would be to, from a host build, generate the entire table of offsets necessary, and then load that for the wasm build, rather than using
offsetofdirectly. I'll look into the viability of this going forward, or if wasm64 support is on the horizon for Safari.