-
Notifications
You must be signed in to change notification settings - Fork 86
Use cmx reachability to decide locality of symbols #1246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Sounds good! I haven't read the code in detail, but from the description I wonder whether there's a missed optimisation: it is in fact possible and useful to have a To see how much impact it's having, I recommend running these commands before and after the change:
These are (approximately,
I'd expect all three to decrease. Also, it's better to measure after configuring with |
Yeah, I was reviewing #1222 and saw that indeed we could do that. I'll try and see what happens. |
I implemented the use of Here are the results of the commands (configured with
|
72ae48f
to
4e5555f
Compare
This builds on top of #1222 .
The first commit adds some useful printing functions, as well as prefix all symbols in the cmm output to indicate whether the symbol is global or local (which is extremely helpful for debugging, as most of the bugs I've come across were because the same symbol was declared and used with different "localities").
The second commit centralizes the handling of symbols in
to_cmm
. Basically, after this commit, all cmm symbols are now generated into_cmm_result.ml
, and there should not be anywhere that still usesstrings
for symbols (instead using either an flambdaSymbol.t
or aCmm.symbol
created by the appropriate function into_cmm_result.ml
).Finally, the third commit uses the name occurrences that are computed during cmx file preparation to decide which symbols should be local. The exact criterion is to use local cmm symbols for symbols from the current compilation unit, and that do not appear in the reachable names.