aboutsummaryrefslogtreecommitdiffstats
path: root/Makefile.in
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2015-01-23 13:12:44 +0100
committerBjörn Gustavsson <[email protected]>2015-02-03 08:40:49 +0100
commitcd1eaf0116190ab72f3a792b74be99eda5dd31eb (patch)
tree0d036a4c6d102d1bd5859c894dd163b6a0a8f0ad /Makefile.in
parent8c3baeb1275c2e6a316d3b5203e0598906785cdb (diff)
downloadotp-cd1eaf0116190ab72f3a792b74be99eda5dd31eb.tar.gz
otp-cd1eaf0116190ab72f3a792b74be99eda5dd31eb.tar.bz2
otp-cd1eaf0116190ab72f3a792b74be99eda5dd31eb.zip
sys_core_fold: Optimize let statements more aggressively
I originally decided that in 'value' context, rewriting a let statement where the variables were not in the body to a sequence was not worth it, because the variables would be unused in only one let in a thousand lets (roughly). I have reconsidered. The main reason is that if we do the rewrite, core_lib:is_var_used/2 will be used much more frequently, which will help us to find bugs in it sooner. Another reason is that the way letify/2 is currently implemented with its own calls to core_lib:is_var_used/2 is only safe as long as all the bindings are independent of each other. We could make letify/2 smarter, but if we introduce this new optimization there is no need. Measuring compilation speed, I have not seen any significant slowdown. It seems that although core_lib:is_var_used/2 is called much more frequently, most calls will be fast because is_var_used/2 will quickly find a use of the variable. Also add a test case to cover a line opt_guard_try/1 that was no longer covered.
Diffstat (limited to 'Makefile.in')
0 files changed, 0 insertions, 0 deletions