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

remove when nimvm condition to import #529

Merged
merged 1 commit into from
Feb 19, 2025
Merged

Conversation

metagn
Copy link
Contributor

@metagn metagn commented Feb 15, 2025

Both branches of a when nimvm statement are compiled, so this import is always processed.

Both branches of a `when nimvm` statement are compiled, so this import is always processed.
@mratsim
Copy link
Owner

mratsim commented Feb 18, 2025

In my case, the import defines slower compile-time impl. I would expect a direct import to shadow the optimized implementations (assembly) that are used at runtime. If when nimvm always compile both branch, is there a way to ensure one is NOT present at runtime?

@metagn
Copy link
Contributor Author

metagn commented Feb 18, 2025

It still only generates C code for the else branches of the when nimvm, so any procs only used in when nimvm would be dead code eliminated. I may have used the wrong word by saying "compiles" but the import statement is still always processed. If importing the module has side effects like initializing a large global then I don't think there's a way around it but procs will not generate if they are not used and code generation for them can be prevented with {.compileTime.} (though this has issues, only recently works with generics and tries to eagerly constant fold every call to it first before erroring).

@mratsim
Copy link
Owner

mratsim commented Feb 18, 2025

So the current code is correct no?

At compile-time I use the code loaded by the when nimvm: import and at runtime I use normal code.

@metagn
Copy link
Contributor Author

metagn commented Feb 19, 2025

In this case (the import) there is no difference between using when nimvm or writing out either branch. Import statements are not processed during code generation but in the typechecking phase, both branches of when nimvm are always typechecked. This also means any symbols defined/imported in either when nimvm branch are always defined/imported, which is misleading and probably something the compiler should catch.

This doesn't mean that these symbols are included in code generation, if procs are only used in contexts that generate code for the VM and not the backend, then dead code elimination will prevent them from being generated. This wouldn't include things like globals as dead code elimination does not apply to them, but in this case there doesn't seem to be any globals. In any case the {.compileTime.} annotation exists for both routines and globals to prevent their generation despite its issues.

@mratsim mratsim merged commit cca0721 into mratsim:master Feb 19, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants