[4.1] disable CFL Alias Analysis by default; fixes known cases of indeterministic build output #309
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've struggled with cdt generating slightly different outputs build-to-build. Typically the number of output permutations is low which allows eventually coming to a consensus between two independent build environments (e.g. two individuals building a contract) by just building over and over until matching up, but clearly this is not ideal behavior and may not always be the case.
The CFL Alias Analysis optimization looks to be the source of the build indeterminism. Disable it by default, and switch the exposed option to allow it to be reenabled in case someone out there really needs it, or finds some severe regression due to the removal of this optimization. (I'm tempted to just remove it entirely: LLVM 9 documents this optimization pass as experimental)
Technically this is a breaking change (removal of
-fno-cfl-aa
option). An alternative is to add the new-fcfl-aa
and keep the existing-fno-cfl-aa
. But then I have to figure out how to properly handle repeated options here (someone passing-fcfl-aa -fno-cfl-aa -fcfl-aa
). I am not really convinced it's worth making this more complex; but we can discuss if someone has a strong opinion about it w.r.t. no breaking changes in a minor release.Disabling this optimization makes a very marginal increase in contract size; I measured two contracts' size in bytes:
FWIW, eosio.evm's stack/data did not increase. I do not have any performance metrics. With such a small change in compiled size it's unlikely there is a significant performance delta, but there is still a chance.