-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Reapply "Implement several peephole optimizations to unblock further optimizations of autodiff code" with correctness fix #62012
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
Conversation
|
Thanks! Could you please highlight (attach a comment to) where the correctness fix is? |
|
@dan-zheng Sure! It's in the separate commit (along with testcases): 63e0083 |
|
@swift-ci please test |
|
Tagging @BradLarson |
dan-zheng
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dan-zheng Sure! It's in the separate commit (along with testcases): 63e0083
Thanks for the pointer! Thanks too for adding tests.
LGTM, though it would be good to get approval from current codebase maintainers. Hope there won't be more breakages.
|
@compnerd @meg-gupta Do CI tests on windows platform enough to ensure the issue is fixed? Or we'd need to do something additionally? |
|
@dan-zheng Apparently it inhibits desired peephole optimizations ( |
|
@asl, no it does not. You need to additionally build the full toolchain. |
|
@swift-ci please test Linux |
|
@swift-ci Please Build Toolchain Windows Platform |
|
@compnerd Looks like different code is generated for AutoDiff/e2e_optimizations.swift on Windows (as compared to Linux / MacOS), this is a bit worrisome to me. Is there a way to obtain SIL dump somehow somewhere? |
|
Unfortunately the toolchain is not available to download from the CI (@shahmishal should be able to help with that). You would have to build the toolchain locally to get that. But I do agree that the difference is something that needs to be investigated before merging. |
|
@compnerd Can I build windows toolchain on Mac M1? I thought that swift and cross-compilation is not something very well compatible. |
|
@asl there is no official support (particularly because there is lack of clarity on some of the legalities of doing so) for cross-compiling from macOS to Windows, but it should be possible to accomplish. |
|
@compnerd Ok. My biggest issue so far is that I need to find windows machine somewhere just to run the installer and get the pre-built SDK. Or maybe there is tarball / zip / whatever that is possible to unpack easily available somewhere for download? |
|
You can extract the contents of the installer using |
|
No wine on M1 :) as it's an aarch64 system. So the only possibility is essentially windows / arm :( |
Installer is available if the build successfully passes. |
|
@compnerd Is windows build / compiler reliable? And results are reproducible? I took the SDK / swift stdlib from the @shahmishal link listed above and tried to cross-compile (from Mac to x86_64-unknown-windows-msvc). I got the same optimized code as on Mac / Linux and test certainly passes. This differs from the FileCheck error dump on CI. |
|
@asl yeah, it is definitely reliable and reproducible. It could be some subtle UB in the compiler itself that is giving different results on Windows compared to Linux/macOS. The Windows compiler is built with |
|
@compnerd Will it be possible for you to compile test/AutoDiff/e2e_optimizations.swift without optimizations with, say, Swift 5.7.1 on Windows and attach the SIL here? |
|
@asl I might be able to do it with a recentish main snapshot, not 5.7.1. I would highly recommend that you build the toolchain if you need to get more details out of this. Can you please provide a command line invocation for the compilation? |
|
I do not have a reasonable way to build a toolchain on Windows, ARM world is quite incompatible with x86 one. I'd not ask if I would have such possibility. Maybe we'd simply mark the test as XFAIL on windows then. I checked the generated code in the Mac / Linux vs cross-compilation on Windows and the only differences were some array-related functions.
Just Thanks! |
|
I don't think that just marking it as XFAIL on windows is appropriate. You can run the Windows VM on ARM. |
|
@compnerd Thanks! The only difference wrt cross-compiled code is the order of users annotation in couple of places. Investigating further. |
|
After lots of plumbing I was able to build a windows toolchain. And the results are worrysome. Result of Result of I will probably open a separate issue to track this instability as it seems to be unrelated to this particular case |
|
The root cause was identified and it is not related to this PR at all. See #62085 (comment) for complete explanation |
|
@swift-ci please test |
|
@swift-ci Please Build Toolchain Windows Platform |
|
@compnerd As far as I can see, windows toolchain has some failed tests that were failing before this PR. Are we good to go? |
|
@compnerd Will you please confirm that fails on windows toolchain are unrelated to this PR and it could be merged? Thanks! |
|
I don't think that it is unrelated ... Sounds like something failed to build and thus the packaging step failed. |
|
@compnerd I'm seeing in the log: As far as I can see, same fails in other PRs that are building windows toolchain, e.g.: #61768 or #61665 |
|
I think that we need to fix the rest of the build to be sure :/ I can try to run the Foundation test suite locally later to verify that those are actually failing without this change. |
|
@compnerd Thanks! |
…ions of autodiff code 1. Simplify differentiable_function_extract of differentiable_function. Before: %x = differentiable_function(%orig, %jvp, %vjp) %y = differentiable_function_extract [original] %x After: %y = %orig 2. Push conversion instructions inside of differentiable_function. This unblocks inlining and specialization. Before: %x = differentiable_function(%orig, %jvp, %vjp) %y = convert_escape_to_noescape %x After: %orig' = convert_escape_to_noescape %orig %jvp' = convert_escape_to_noescape %jvp %vjp' = convert_escape_to_noescape %vjp %y = differentiable_function(%orig', %jvp', %vjp') 3. Another peephole is needed for reordering function conversion instructions to enable full inlining: (convert_escape_to_noescape (convert_function (thin_to_thick_function x))) => (convert_escape_to_noescape (thin_to_thick_function (convert_function x))) Co-authored-by: Dan Zheng <danielzheng@google.com>
…oken - It is certainly not something mandatory
…t available on Windows native builds
0835561 to
4e7d70e
Compare
|
@swift-ci please test |
|
@swift-ci Please Build Toolchain Windows Platform |
|
@swift-ci Please test Windows platform |
The PR reapplies #60520 along with correctness fix – we only do the transformation when it is safe (the inner values have single use)
Fixes #61731