BREAKING CHANGE: Revise default optimization level #1776
Conversation
|
Perhaps an agenda item for later today: Should the first bullet trigger a breaking change? If so, I'd probably split this. |
cli/asc.json
Outdated
| "-O3z": { "value": { "optimizeLevel": 3, "shrinkLevel": 2 } } | ||
| "-O3z": { "value": { "optimizeLevel": 3, "shrinkLevel": 2 } }, | ||
| "-Ospeed": { "value": { "optimizeLevel": 3, "shrinkLevel": 0 } }, | ||
| "-Osize": { "value": { "optimizeLevel": 0, "shrinkLevel": 2, "converge": true } } |
There was a problem hiding this comment.
Hmm, does optimizeLevel: 0 really beter than optimizeLevel: 3 for size shrinking?
There was a problem hiding this comment.
Would assume it depends. If there is a lot that can be inlined for example, it would depend on how well it optimizes away afterwards. If it doesn't, not inlining in the first place may be better.
There was a problem hiding this comment.
The std/array test produces exactly the same binary size with both -O3z and -Oz. The bootstrapped compiler seems to have a difference of a couple bytes: 838.188 with -O3z vs 838.155 with -Oz.
|
Oh! And I think we discussed in the CG meeting, that we might want to make this PR breaking. Or, split out the non-breaking flag changes into another PR. And then make this one as a part of whatever the next breaking change is? 😄 |
dcodeIO
changed the title
dcodeIO
changed the title
Changes default optimization levels for
--optimizerespectively-OtooptimizeLevel=3andshrinkLevel=0(wasshrinkLevel=1), since-O3s, which was intended as a compromise, doesn't appear to be very useful in practice. Afterwards,-Ois equivalent to-O3respectively-Ospeed.fixes #1753