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
[safepoint] Use LLVM pass to insert safepoint #11789
Conversation
b5aac5f
to
27a06af
Compare
27a06af
to
47518b4
Compare
This is to avoid safepoints to stop optimizations from happening.
47518b4
to
4150f06
Compare
This is to avoid safepoints to stop optimizations from happening.
To continue the example from @EgorBo from #11729: using System;
public class Hello {
public static void Main (string []args)
{
System.Console.WriteLine ("sum: " + SumUp());
}
public static int SumUp ()
{
int sum = 0;
for (int i = 0; i < 5; i++)
sum += i;
return sum;
}
} Before: _Hello_SumUp:
960: 53 pushq %rbx
961: 48 8b 1d 68 09 00 00 movq 2408(%rip), %rbx
968: 48 83 3b 00 cmpq $0, (%rbx)
96c: 74 05 je 5 <_Hello_SumUp+0x13>
96e: e8 dd 00 00 00 callq 221 <plt__jit_icall_mono_threads_state_poll>
973: 48 83 3b 00 cmpq $0, (%rbx)
977: 74 05 je 5 <_Hello_SumUp+0x1e>
979: e8 d2 00 00 00 callq 210 <plt__jit_icall_mono_threads_state_poll>
97e: 48 83 3b 00 cmpq $0, (%rbx)
982: 74 05 je 5 <_Hello_SumUp+0x29>
984: e8 c7 00 00 00 callq 199 <plt__jit_icall_mono_threads_state_poll>
989: 48 83 3b 00 cmpq $0, (%rbx)
98d: 74 05 je 5 <_Hello_SumUp+0x34>
98f: e8 bc 00 00 00 callq 188 <plt__jit_icall_mono_threads_state_poll>
994: 48 83 3b 00 cmpq $0, (%rbx)
998: 74 05 je 5 <_Hello_SumUp+0x3f>
99a: e8 b1 00 00 00 callq 177 <plt__jit_icall_mono_threads_state_poll>
99f: 48 83 3b 00 cmpq $0, (%rbx)
9a3: 74 05 je 5 <_Hello_SumUp+0x4a>
9a5: e8 a6 00 00 00 callq 166 <plt__jit_icall_mono_threads_state_poll>
9aa: b8 0a 00 00 00 movl $10, %eax
9af: 5b popq %rbx
9b0: c3 retq LLVM unrolls the loop and can do constant folding, but doesn't understand the semantics of our safepoints and thus can't squash them together. With this PR: _Hello_SumUp:
9c0: 48 83 3d 08 09 00 00 00 cmpq $0, 2312(%rip)
9c8: 74 0b je 11 <_Hello_SumUp+0x15>
9ca: 50 pushq %rax
9cb: ff 15 07 09 00 00 callq *2311(%rip)
9d1: 48 83 c4 08 addq $8, %rsp
9d5: b8 0a 00 00 00 movl $10, %eax
9da: c3 retq LLVM can be awesome. Nice work @luhenry 👍 |
public static unsafe int GetValue(int* n)
{
return *n;
} mono-luhenry generates the following IR: define hidden monocc i32 @P_GetValue_int_(i64* nocapture readonly %arg_n) #3 gc "mono" {
BB0:
%0 = bitcast i64* %arg_n to i32*
%t20 = load i32, i32* %0, align 4
%1 = load i64, i64* bitcast (i64** getelementptr inbounds ([27 x i64*], [27 x i64*]* @mono_aot_Program_llvm_got, i64 0, i64 24) to i64*), align 16
%2 = icmp eq i64 %1, 0
br i1 %2, label %gc.safepoint_poll.exit, label %gc.safepoint_poll.poll.i
gc.safepoint_poll.poll.i: ; preds = %BB0
%3 = load void ()*, void ()** bitcast (i64** getelementptr inbounds ([27 x i64*], [27 x i64*]* @mono_aot_Program_llvm_got, i64 0, i64 25) to void ()**), align 8
call void %3() #8
br label %gc.safepoint_poll.exit
gc.safepoint_poll.exit: ; preds = %BB0, %gc.safepoint_poll.poll.i
ret i32 %t20
} ^ temp.opt.bc ( while mono-master generates (thanks to #11554): ; Function Attrs: norecurse nounwind readonly uwtable
define hidden monocc i32 @P_GetValue_int_(i64* nocapture readonly %arg_n) #2 {
BB0:
%0 = bitcast i64* %arg_n to i32*
%t20 = load i32, i32* %0, align 4
ret i32 %t20
} Ideally it could be just: define hidden monocc i32 @P_GetValue_int_(i32* nocapture readonly %arg_n) #3 gc "mono" {
%0 = load i32, i32* %arg_n, align 4
ret i32 %0
} (i32* instead of i64*+bitcast for my |
@luhenry I guess we can still use that optimization and just don't mark this kind of simple methods with |
Do we still want this in its current form, @luhenry ? Looks like there's some merge conflict to resolve |
@lambdageek if you want to take it over, that would be most useful. The latest issue is with finding the right linking strategy for |
@luhenry you mean we have to decide which AOT image gets the safepoint function? wouldn't we want it to have internal (static) linkage and an inline hint so that every AOT image has its own copy that is inlined at the call sites? |
so the crash happens because we jump to an offset in the GOT that is null. https://gist.github.com/alexanderkyte/634c9f1f25b7eb252e4d5fb4ea3c2fcf |
Not sure why that happens, I'd suggest adding it to |
Thanks @vargaz, trying that now. |
Will fix |
@lambdageek seems a bit weird to be seeing this on the OSX desktop lane. It seems like it's definitely related to the area of the runtime that this changes though. |
Seeing some failures on Cannot reproduce on OSX at all. Will attempt at home on linux machine. @lambdageek would a safepoint triggering on an overflowing stack be correctly identified? I'm not sure what of the many types of fixes for that would be the least disruptive. |
If you question is "can the code for a safepoint be called when the stack is overflowing"? I'm pretty sure the answer is no:
If I had to guess, LLVM and mono's old mechanism are placing the safepoint in slightly different places with respect to the |
Difficulties reproducing on my linux desktop, but I think I have a good defensive strategy after looking over it. Will push a fix tomorrowish and see what CI finds. |
After some poking, I don't think I'm going to be able to prevent this without reproducing. Let me redouble my efforts and try an ubuntu VM on my linux host with the same version we use. |
I've been able to repro now. Looking into it. |
Looks like it's trying to lazily init the trampoline during the StackOverflow.
|
Looks like it will break outside of init as well. Why this wasn't happening before, I'm not sure.
|
We are still observing the following error on iOS SDK:
|
@luhenry interesting, I hadn't been looking for that one. Looks like a static linking issue. Will fix. |
@monojenkins build failed |
Looks like this should be good to merge once those two arm lanes come back. |
@alexanderkyte thanks for pushing it through! :) |
- Use python tool.mk instead of searching more files to patch @PYTHONBIN@ in. - Add some preliminary ideas for how to get netbsd/aarch64 and solaris working. it shouldn't be enough to complete a build. (They can't use Mono's outdated libgc) notable for us, this release re-adds FreeBSD supports. Mono 6.4.0 release notes: Highlights C# compiler support for C# 8 language version .NET Standard 2.1 support Updated libgdiplus to 6.0.2 Notarized macOS installer package In Depth Runtime Hardened Runtime and Notarization support on macOS The Mono binary installed by the .pkg for macOS is now using the Hardened Runtime capabilities and the package was notarized to comply with Apple’s new restrictions: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution. This allows the package to work on the upcoming macOS 10.15 Catalina without showing warning dialogs. Interpreter improvements The Mono interpreter was updated to support the Windows operating system. We also completed a lot of groundwork for upcoming future optimizations in the interpreter, like constant folding. Bitness independent AOT cross compiler The Ahead-Of-Time (AOT) cross compiler was updated to no longer require being executed with the same bitness that it should generate code for. This means a 64bit Mono can now emit AOT code for 32bit targets. This work was mainly done to support executing the AOT cross compiler on macOS 10.15 Catalina (which is 64bit only) as we still need to generate code for 32bit targets like older iPhone and Apple Watch devices. WebAssembly We continue to work on making our WebAssembly support better. Various sets of issues with the debugger have been resolved in this release and general performance and feature work is happening as well. LLVM improvements We now leave it up to the LLVM framework to insert safepoints. Later optimizations can understand safepoints then which leads to better generated code. See mono/mono#11789 The LLVM backend is also supported on the Windows operating system now. PPC JIT optimizations The PowerPC JIT received a bunch of optimization from community contributor Calvin Buckley (@NattyNarwhal). Experimental build support for Fuchsia A very minimal and experimental support for building Mono targeting the Fuchsia OS landed in the build system. Class Libraries .NET Standard 2.1 support We updated our class libraries to support the latest additions to .NET Standard. You can now run a library compiled against the .NET Standard 2.1 specification on Mono. CoreFX integration We continued to replace some of our classes with the implementation from CoreFX to improve performance and compatibility with .NET. libgdiplus update to 6.0.2 The libgdiplus native library is used for implementing System.Drawing on Unix platforms. This release contains many important improvements from our community members. Special thanks go to Hugh Bellamy (@hughbe), Frederik Carlier (@qmfrederik) and Filip Navara (@filipnavara) for their awesome contributions! System.Windows.Forms More fixes and layout improvements for different controls made by external contributors have landed in this release . Tools C# 8 language version support in csc and msbuild The C# compiler and msbuild tooling were updated to versions that support the final C# 8 language specification. The Default Interface Methods (DIM) feature also received a few runtime enhancements. NuGet Bundled NuGet version has been upgraded to 5.2 RTM.
- Use python tool.mk instead of searching more files to patch @PYTHONBIN@ in. - Add some preliminary ideas for how to get netbsd/aarch64 and solaris working. it shouldn't be enough to complete a build. (They can't use Mono's outdated libgc) notable for us, this release re-adds FreeBSD supports. Mono 6.4.0 release notes: Highlights C# compiler support for C# 8 language version .NET Standard 2.1 support Updated libgdiplus to 6.0.2 Notarized macOS installer package In Depth Runtime Hardened Runtime and Notarization support on macOS The Mono binary installed by the .pkg for macOS is now using the Hardened Runtime capabilities and the package was notarized to comply with Apple’s new restrictions: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution. This allows the package to work on the upcoming macOS 10.15 Catalina without showing warning dialogs. Interpreter improvements The Mono interpreter was updated to support the Windows operating system. We also completed a lot of groundwork for upcoming future optimizations in the interpreter, like constant folding. Bitness independent AOT cross compiler The Ahead-Of-Time (AOT) cross compiler was updated to no longer require being executed with the same bitness that it should generate code for. This means a 64bit Mono can now emit AOT code for 32bit targets. This work was mainly done to support executing the AOT cross compiler on macOS 10.15 Catalina (which is 64bit only) as we still need to generate code for 32bit targets like older iPhone and Apple Watch devices. WebAssembly We continue to work on making our WebAssembly support better. Various sets of issues with the debugger have been resolved in this release and general performance and feature work is happening as well. LLVM improvements We now leave it up to the LLVM framework to insert safepoints. Later optimizations can understand safepoints then which leads to better generated code. See mono/mono#11789 The LLVM backend is also supported on the Windows operating system now. PPC JIT optimizations The PowerPC JIT received a bunch of optimization from community contributor Calvin Buckley (@NattyNarwhal). Experimental build support for Fuchsia A very minimal and experimental support for building Mono targeting the Fuchsia OS landed in the build system. Class Libraries .NET Standard 2.1 support We updated our class libraries to support the latest additions to .NET Standard. You can now run a library compiled against the .NET Standard 2.1 specification on Mono. CoreFX integration We continued to replace some of our classes with the implementation from CoreFX to improve performance and compatibility with .NET. libgdiplus update to 6.0.2 The libgdiplus native library is used for implementing System.Drawing on Unix platforms. This release contains many important improvements from our community members. Special thanks go to Hugh Bellamy (@hughbe), Frederik Carlier (@qmfrederik) and Filip Navara (@filipnavara) for their awesome contributions! System.Windows.Forms More fixes and layout improvements for different controls made by external contributors have landed in this release . Tools C# 8 language version support in csc and msbuild The C# compiler and msbuild tooling were updated to versions that support the final C# 8 language specification. The Default Interface Methods (DIM) feature also received a few runtime enhancements. NuGet Bundled NuGet version has been upgraded to 5.2 RTM.
Depends on mono/llvm#35