other.test_minimal_runtime_code_size: apply slop to code sizes #8364
Conversation
This file contains 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
…ere is a source of nondeterminism in the JS backend
sbc100
approved these changes
Mar 28, 2019
tests/test_other.py
Outdated
| @@ -9080,9 +9080,11 @@ def print_percent(actual, expected): | |||
| print('size of ' + f + ' == ' + str(size) + ', expected ' + str(expected_size) + ', delta=' + str(size - expected_size) + print_percent(size, expected_size)) | |||
|
|
|||
| # Hack: Generated .mem initializer files have different sizes on different platforms (Windows gives x, CircleCI Linux gives x-17 bytes, my home Linux gives x+2 bytes..) | |||
| # TODO: identify what is causing this (until that, expected .mem initializer file sizes are conservative estimates that do not contribute to total size) | |||
| # Likewise asm.js files seem to be affected by the LLVM IR text names, which lead to asm.js names, which leads to difference code size, which leads to different | |||
There was a problem hiding this comment.
Can you wrap these lines at 80?
VirtualTim
pushed a commit
to VirtualTim/emscripten
that referenced
this pull request
May 21, 2019
…ipten-core#8364) As there is a source of nondeterminism in the JS backend - LLVM IR text names affect asm.js names, which leads to difference code size, which leads to different code sizes. In particular, on the exact same fastcomp+emscripten I get 7 byte larger code sizes locally than the bots do. This appears to have gotten more random since the recent change to LLVM IR debug name changes, but it was probably a problem all along, just became more noticeable. This appears to be a JS backend issue, so it should not exist with the wasm backend, once we switch over.
VirtualTim
added a commit
to VirtualTim/emscripten
that referenced
this pull request
May 23, 2019
VirtualTim
added a commit
to VirtualTim/emscripten
that referenced
this pull request
May 23, 2019
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.
As there is a source of nondeterminism in the JS backend - LLVM IR text names affect asm.js names, which leads to difference code size, which leads to different code sizes. In particular, on the exact same fastcomp+emscripten I get 7 byte larger code sizes locally than the bots do. This appears to have gotten more random since the recent change to LLVM IR debug name changes, but it was probably a problem all along, just became more noticeable.
This appears to be a JS backend issue, so it should not exist with the wasm backend, once we switch over.