Skip to content

Remove -enable-ossa-modules for Synchronization and Distributed #77314

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

Merged
merged 9 commits into from
Nov 4, 2024

Conversation

meg-gupta
Copy link
Contributor

@meg-gupta meg-gupta commented Oct 31, 2024

Synchronization and Distributed are serialized in OSSA, they import Darwin which is non-ossa. With implicit modules builds, this results in a one time recompilation of Darwin with -enable-ossa-modules.
However with Explicit Build Modules, all dependencies are treating equally and -enable-ossa-modules will be passed on only when present in the original compiler invocation.

This PR removes -enable-ossa-modules for Synchronization and Distributed and adds a diagnostic whenever we are trying to import a non-ossa module into an ossa module when Explicit Build Modules are enabled.

As a consequence one of the perf constraint tests in Synchronization started failing due to presence of copies which was previously eliminated due to being in ossa. I added @_transparent to the relevant stdlib function - Atomic.deinit to workaround this since @_transparent functions are always serialized as ossa irrespective of the presence of -enable-ossa-modules.

This is a temporary fix until ossa modules are default.

Fixes rdar://138407068

@meg-gupta
Copy link
Contributor Author

@swift-ci smoke test

@meg-gupta
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#9492

@swift-ci Please test

@meg-gupta meg-gupta changed the title Remove -enable-ossa-module for Synchronization and Distributed Remove -enable-ossa-modules for Synchronization and Distributed Oct 31, 2024
@Azoy
Copy link
Contributor

Azoy commented Oct 31, 2024

Is this really easier than just adding -enable-ossa-modules to the Darwin module? Do you have an estimated timeline of when -enable-ossa-modules will be turned on by default?

@@ -353,6 +353,9 @@ set(swiftCore_common_options
SWIFT_COMPILE_FLAGS
${swift_stdlib_compile_flags} -Xcc -DswiftCore_EXPORTS ${SWIFT_STANDARD_LIBRARY_SWIFT_FLAGS})

# Enable OSSA Modules for swift stdlib
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you can remove this since it comes for free with the changes in stdlib/cmake/modules/AddSwiftStdlib.cmake.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
@meg-gupta
Copy link
Contributor Author

@Azoy Adding -enable-ossa-modules to Darwin will also need adding it to its dependencies which are multiple in number.

@meg-gupta
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#9492

@swift-ci Please test

// soft reject, silently ignore.
// Diagnose only when explicit build modules is enabled
if (Ctx.SerializationOpts.ExplicitModuleBuild) {
Ctx.Diags.diagnose(diagLoc,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this only diagnosed for explicit module builds?

Copy link
Contributor Author

@meg-gupta meg-gupta Oct 31, 2024

Choose a reason for hiding this comment

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

I have left the behavior as is for implicit module builds. It's useful for testing -enable-ossa-modules on a module level until support for implicit module builds exist.

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be possible to instead introduce a flag that allows OSSA to be lenient for testing, while making both explicit and implicit module builds strict in the same way by default?

@meg-gupta meg-gupta requested a review from atrick October 31, 2024 18:33
Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

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

Basically looks good to me

@@ -901,6 +901,9 @@ ERROR(serialization_target_too_new_repl,none,
"deployment target of %0 %3: %4",
(StringRef, llvm::VersionTuple, Identifier, llvm::VersionTuple,
StringRef))
ERROR(serialization_non_ossa_module_incompatible, Fatal,
"cannot import non-ossa module into an ossa-module",
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe:
"cannot import non-OSSA module into an OSSA module"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@meg-gupta meg-gupta force-pushed the ossaflag branch 2 times, most recently from 6d44548 to 6a718be Compare October 31, 2024 20:50
Copy link
Contributor

@ktoso ktoso left a comment

Choose a reason for hiding this comment

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

Not entirely sure on the implications for the Distributed module but seems fine to me?

@meg-gupta
Copy link
Contributor Author

@swift-ci test

@meg-gupta meg-gupta enabled auto-merge November 2, 2024 23:49
@meg-gupta
Copy link
Contributor Author

@swift-ci test

@meg-gupta
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#9492

@swift-ci Please test

@meg-gupta
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#9492

@swift-ci Please test

@meg-gupta
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#9492

@swift-ci Please test windows platform

@meg-gupta meg-gupta merged commit c0a55e1 into swiftlang:main Nov 4, 2024
5 checks passed
@felipepiovezan
Copy link
Contributor

Hi @meg-gupta , this PR broke the LLDB builds: https://ci.swift.org/view/LLDB/job/oss-lldb-incremental-macos-cmake/8289/console

Whenever an API in ASTContext.h changes, it is advisable to build LLDB as well, as it is one client of that API.

@adrian-prantl
Copy link
Contributor

@shahmishal Why didn't the pre-merge CI catch this?

@shahmishal
Copy link
Member

@adrian-prantl the llvm change it was tested with was never merged

@adrian-prantl
Copy link
Contributor

@adrian-prantl the llvm change it was tested with was never merged

that's a relief, I was worried that during the rebranch we introduced a bot misconfiguration!

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.

8 participants