Remove unnecessary control flow#10363
Conversation
This reverts commit 1458a5d.
This reverts commit c70fb47.
|
Here are some simple changes in the Hello sample that are caused by this patch: The first shows the main point of the change, that return should have been optimized out when the rest of the method was removed. Original Java for reference: gwt/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java Lines 349 to 357 in 1ad2adf I didn't chase the rest of the optimization, but likely the sCaptureElem field is always null for this project, so the first if is always true, and the rest of the method goes away.
Compiling the Showcase shows that Tree has another such example gwt/user/src/com/google/gwt/user/client/ui/Tree.java Lines 1114 to 1120 in 1ad2adf IntelliJ calls out this pointless return at least, and the optimized output also loses the default and preceding `break.
This is one of a handful of "okay, maybe developers do leave in useless keywords" that we can benefit from (see also PopupPanel, AbstractHasData, SplitPanel, SplitLayoutPanel, CellBrowser, CellTree, CellGridImpl, ...). With that said, the largest Showcase permutation only loses about 100 bytes from just this patch, about 0.05%, while Hello loses about 7 bytes. EDIT Updated to reflect comparing compiled output with that of #10270, which should merge first. |
|
These long running branches got me a little backwards - most of this could/should be moved over to #10270 to make this patch a little simpler, and that PR should land first. I'll make that change so this PR is a little more focused. |
Removes trailing returns in methods and non-loop blocks, breaks in switches, and continues in loops. Returns at the end of loops can be replaced by breaks if the loop is the last statement of the method. By itself, will make no difference in runtime performance, but by removing these can reduce simple byte count and and avoid the appearance of control flow that could prevent pruning or inlining.
Generally speaking, this seems like a silly optimization to make - developers won't end void methods with
returnor loop blocks withcontinue, but as other code gets optimized away, these end up being left and can't be removed any other way.There is a risk here for size regressions through making a method easier to inline, though adding explicit return isn't intended as a way to preventing inlining.
This is a necessary prerequisite for #10240 to avoid risking avoidable size regressions.
Fixes #10248