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

Changing multithreading mode does not trigger clean build #3567

Open
WojciechMazur opened this issue Oct 11, 2023 · 0 comments · May be fixed by #3575
Open

Changing multithreading mode does not trigger clean build #3567

WojciechMazur opened this issue Oct 11, 2023 · 0 comments · May be fixed by #3575
Assignees
Milestone

Comments

@WojciechMazur
Copy link
Contributor

When switching from multithreadingSupport=false -> true while having incremental compilation enabled, I've seen that the toolchain would not start a new, clean build, but would rather use the already compiled .ll files. Normally it would be expected, when using the same config, as it allows to skip redundant work. However, when build changes to produced outputs shall also change, and should not be reused!. Especially in case of multithreading which does change a way in which we do lower Op.Module operations. This leads to compilation errors until doing a manual cleanup.

Fix: Make sure that when NativConfig changes the backend does not use cached .ll files

@WojciechMazur WojciechMazur added this to the 0.5.0 milestone Oct 11, 2023
@tanishiking tanishiking self-assigned this Oct 16, 2023
tanishiking added a commit to tanishiking/scala-native that referenced this issue Oct 18, 2023
…Config changes

Fix: scala-native#3567

Previously, the scala-native would not start a new, clean build when switching from `multithreadingSupport=false -> true`
while having incremental compilation enabled.
This was because it would reuse the already compiled cached native-lib nir files.
However, when `nativeConfig` (especially `multithreadingSupport`) changes, which affects the native-lib code
scala-native shouldn't reuse the cached native-lib.
This led to compilation errors until doing a manual cleanup.

This commit fixes this issue by removing stale native-config-* directories when the `nativeConfig` changes.
To do that, we added a hashCode of nativeConfig to the native-lib's
directories.

```
❯ ls -l sandbox/.3/target/scala-3.3.1/native | grep native-code
... native-code-clib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-1/
... native-code-javalib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-2/
... native-code-nativelib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-0/
... native-code-posixlib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-3/
... native-code-windowslib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-4/
```
tanishiking added a commit to tanishiking/scala-native that referenced this issue Nov 10, 2023
…Config changes

Fix: scala-native#3567

Previously, the scala-native would not start a new, clean build when switching from `multithreadingSupport=false -> true`
while having incremental compilation enabled.
This was because it would reuse the already compiled cached native-lib nir files.
However, when `nativeConfig` (especially `multithreadingSupport`) changes, which affects the native-lib code
scala-native shouldn't reuse the cached native-lib.
This led to compilation errors until doing a manual cleanup.

This commit fixes this issue by removing stale native-config-* directories when the `nativeConfig` changes.
To do that, we added a hashCode of nativeConfig to the native-lib's
directories.

```
❯ ls -l sandbox/.3/target/scala-3.3.1/native | grep native-code
... native-code-clib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-1/
... native-code-javalib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-2/
... native-code-nativelib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-0/
... native-code-posixlib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-3/
... native-code-windowslib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-4/
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants