-
Notifications
You must be signed in to change notification settings - Fork 127
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
Long compile times for RedPRL #196
Comments
Incidentally, I was talking about this with Frank Pfenning today and he said he had a similar issue using MLton to build the compiler for C0, and he worked around it by breaking up large case statements into auxiliary functions... I wonder if something is getting out of control in that neighborhood. |
@jonsterling I don't think that large (source) case statements are the problem, but mentioning C0 made me remember that @robsimmons reported a similar issue about C0: https://sourceforge.net/p/mlton/mailman/message/31031310/ I think that the comments in that thread are probably relevant. In particular, that code is being generated that has worst-case liveness analysis. Looking at some of the intermediate language programs during a compilation of |
BTW, compiling
|
@MatthewFluet Thank you, that did the trick! |
Closes RedPRL#437 MLton's `polyvariance` optimization duplicates small higher-order functions. One (unresolved, though usually not significant) issue is that polyvariance can duplicate code local to a function, even if it doesn't depend on the higher-orderness (see http://www.mlton.org/pipermail/mlton-devel/2002-January/021211.html). This seems consistent with the discussion at MLton/mlton#196.
Closes #437 MLton's `polyvariance` optimization duplicates small higher-order functions. One (unresolved, though usually not significant) issue is that polyvariance can duplicate code local to a function, even if it doesn't depend on the higher-orderness (see http://www.mlton.org/pipermail/mlton-devel/2002-January/021211.html). This seems consistent with the discussion at MLton/mlton#196.
See RedPRL/sml-redprl#394; present at RedPRL/sml-redprl@ba89d59.
Both the native amd64 and C codegens exhibit excessively long compile times (> 10min), which suggests that the Machine IR program has some inherent structure that is poorly handled. The C codegen generates a file with 28807 local
CPointer
variables, which takesgcc
>10min to compile.The text was updated successfully, but these errors were encountered: