Skip to content
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

fix --compile=all option, and some improvements for --strip-ir #46935

Merged
merged 1 commit into from Sep 30, 2022

Conversation

JeffBezanson
Copy link
Sponsor Member

@JeffBezanson JeffBezanson commented Sep 27, 2022

--compile=all has been broken for several releases. What it's supposed to do is simply compile one generic implementation (i.e. specialized for the declared argument types of a method) for each method, so that programs can run without the compiler or IR present.

Fixes calling return_type in images built with --strip-ir; we were just missing a nothing check.

Also don't bother compiling code for the type inference world when using --strip-ir. (Left this out for now in the interest of minimizing disruption.) It would be good to be able to exclude Core.Compiler entirely in that case, but it's not trivial due to return_type.

Also make --compile and module-level settings take precedence over force_compile metadata.

Obviously, this could use tests --- maybe it can be tested as part of PackageCompiler?

Possible future work: remove the Method.unspecialized field, since all it does is cache the lookup of one specialization, but that lookup should only be done in slow paths.

@JeffBezanson JeffBezanson added bugfix This change fixes an existing bug backport 1.8 Change should be backported to release-1.8 labels Sep 27, 2022
src/precompile.c Outdated Show resolved Hide resolved
src/aotcompile.cpp Outdated Show resolved Hide resolved
{
jl_array_t *found = (jl_array_t*)env;
// method definition -- compile template field
jl_array_t *allmeths = (jl_array_t*)env;
jl_method_t *m = ml->func.method;
if (m->source) {
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we try to normalize on whether !source or source == jl_nothing implies the absence of source code?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes sounds like a good idea.

src/precompile.c Outdated Show resolved Hide resolved
@KristofferC
Copy link
Sponsor Member

Obviously, this could use tests --- maybe it can be tested as part of PackageCompiler?

It could, what would be a good test? Just compile a new sysimage with --compile=all and run some stuff?

@KristofferC KristofferC mentioned this pull request Sep 30, 2022
37 tasks
@JeffBezanson JeffBezanson merged commit 6443a46 into master Sep 30, 2022
@JeffBezanson JeffBezanson deleted the jb/compileall branch September 30, 2022 19:57
JeffBezanson added a commit that referenced this pull request Oct 27, 2022
KristofferC pushed a commit that referenced this pull request Oct 27, 2022
KristofferC added a commit that referenced this pull request Oct 28, 2022
KristofferC added a commit that referenced this pull request Oct 28, 2022
KristofferC pushed a commit that referenced this pull request Oct 28, 2022
…46935) (#47357)

(cherry picked from commit 6443a46)
(cherry picked from commit 3562f03)
KristofferC pushed a commit that referenced this pull request Oct 28, 2022
…46935) (#47357)

(cherry picked from commit 6443a46)
(cherry picked from commit 3562f03)
@KristofferC KristofferC removed the backport 1.8 Change should be backported to release-1.8 label Nov 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants