Arm32 Libraries tests failures with full PGO #53549
Assignees
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone
Comments
dotnet-issue-labeler
bot
added
area-System.Collections
untriaged
|
Tagging subscribers to this area: @eiriktsarpalis Issue Detailsfullpgo arm32 failures in a number of array enumerator tests:
|
AndyAyersMS
added
area-CodeGen-coreclr
|
Also whenever I run on arm via a checked corerun I get a slew of unwanted output from the runtime, some sort of directory probing : |
|
Trying to repro but getting other random-looking failures, currently. |
|
I can't repro the issues and from the test history it looks like these tests are not always failing. So will wait for this weekend's runs to see if any clearer pattern emerges. |
|
Looking at the last weekend runs the sets of failures seem to fluctuate, but there's a common failure mode where an object is unexpectedly null. This seems to happen across all architectures (though more commonly for arm/arm64) so likely is some high level transformation. |
|
More than arm32 failing, need to investigate |
|
Not sure if it's the same issue but I can get libraries tests to fail with PGO enabled if I add |
|
For the IN0016: 000091 vmovupd xmmword ptr [0000H], xmm0and not surprisingly this leads to an NRE at runtime. |
|
Looks like this is a bug in the GDV expansion for a call returning a struct value that is the payload of a box. Normally we'd allocate the box object and then make the call, but with GDV we can end up making the call first. More details forthcoming... |
|
Here's a simple repro. using System;
using System.Runtime.CompilerServices;
using System.Threading;
interface I
{
public Decimal F();
}
class X : I
{
Decimal z;
public Decimal F() => z;
public static bool G(object o)
{
return ((decimal) o).Equals(100M);
}
[MethodImpl(MethodImplOptions.NoInlining)]
public static int H(I i)
{
return G(i.F()) ? 100 : -1;
}
public static int Main()
{
X x = new X();
x.z = 100M;
for (int i = 0; i < 100; i++)
{
_ = H(x);
Thread.Sleep(15);
}
return H(x);
}
}When H is recompiled at Tier1, GDV kicks in, and we end up with bad code: 48B8D0A2141AF97F0000 mov rax, 0x7FF91A14A2D0 // gdv test for i
483901 cmp qword ptr [rcx], rax
0F85BD000000 jne G_M22385_IG13
C5F9104108 vmovupd xmm0, xmmword ptr [rcx+8] // blown box init
C5F911042500000000 vmovupd xmmword ptr [0000H], xmm0and hence an exception |
|
cc @EgorBo in case you're interested or have run across this ... still looking for a fix that does not require losing some GDV. |
AndyAyersMS
added a commit
to AndyAyersMS/runtime
that referenced
this issue
Jul 22, 2021
If a call is a GDV candidate and returns a struct via hidden buffer, and that return value is immediately boxed, the GDV expansion will produce IR in incorrect order, leading to bad codegen. This seems to be a rare enough sequence that disabling GDV is a reasonable workaround for now. Actually the box expansion is producing IR in the wrong order and GDV fails to fix the order (unlike inlining, which does fix the order). Longer term we should avoid producing out of order IR. But that seems a bit more complicated and may have other CQ impact. Added a test case. Closes dotnet#53549.
ghost
added
the
in-pr
AndyAyersMS
added a commit
that referenced
this issue
Jul 22, 2021
If a call is a GDV candidate and returns a struct via hidden buffer, and that return value is immediately boxed, the GDV expansion will produce IR in incorrect order, leading to bad codegen. This seems to be a rare enough sequence that disabling GDV is a reasonable workaround for now. Actually the box expansion is producing IR in the wrong order and GDV fails to fix the order (unlike inlining, which does fix the order). Longer term we should avoid producing out of order IR. But that seems a bit more complicated and may have other CQ impact. Added a test case. Closes #53549.
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
From https://dev.azure.com/dnceng/public/_build/results?buildId=1163507&view=ms.vss-test-web.build-test-results-tab,
fullpgo arm32 failures in a number of array enumerator tests:
The text was updated successfully, but these errors were encountered: