summaryrefslogtreecommitdiff
path: root/src/passes/TupleOptimization.cpp
diff options
context:
space:
mode:
authorGoktug Gokdogan <goktug@google.com>2023-12-12 14:08:21 -0800
committerGitHub <noreply@github.com>2023-12-12 22:08:21 +0000
commitda18e25f22afcd916171aae8511c7b6860d4d7cc (patch)
treee920a053051b09ec936392943787cc802f8e9fbd /src/passes/TupleOptimization.cpp
parenta6c1165db639e505d68758b14256492ede57e362 (diff)
downloadbinaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.tar.gz
binaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.tar.bz2
binaryen-da18e25f22afcd916171aae8511c7b6860d4d7cc.zip
J2CL: Add extra guardrails (#6171)
The patch puts a new guardrail that will only hoist the field if it is initialized with the owner class. The constant hoisting optimization in J2CL pass relies on the assumption that clinit that will initialize the field will be executed before the read of the field. That means the field that is optimized is within the same class: class Foo { public static final Object field = new Object(); } Although it is possible to observe the initial value, that is not intention of the developer (which the point of the optimization). However can also see a similar pattern in following: class Foo { public static Object field; } class Zoo { static { Foo.field = new Object(); } } Currently the pass also optimizes it as well since the field is only initialized once and by a clinit. However Zoo clinit is not guaranteed to be run before Foo.field access so it is less safe to speculate on the intention of the developer here hence it is not worth the risk. FWIW, we haven't seen this issue. But this is something we are also guarding in Closure Compiler so I decided it is worthwhile to do here as well.
Diffstat (limited to 'src/passes/TupleOptimization.cpp')
0 files changed, 0 insertions, 0 deletions