[arm64] JIT: Redundant zero/sign extensions after ldrX/ldrsX

[EgorBo]

Just a quick peephole opt to drop redundant zero extensions after ldr, seems to have some nice asm diffs: up to -177648 bytes: https://dev.azure.com/dnceng/public/_build/results?buildId=1508477&view=ms.vss-build-web.run-extensions-tab

Minimal repro:

static ulong Foo(ref uint p) => p;

Codegen diff:

; Method Prog:Foo(byref):long
G_M41239_IG01:
            stp     fp, lr, [sp,#-16]!
            mov     fp, sp
G_M41239_IG02:
            ldr     w0, [x0]
-           mov     w0, w0
G_M41239_IG03:
            ldp     fp, lr, [sp],#16
            ret     lr
-; Total bytes of code: 24
+; Total bytes of code: 20

Closes #35254

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Just a quick peephole to drop redundant zero extensions after ldr, seems to have some nice asm diffs..

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

/azp run Fuzzlyn, Antigen

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

/azp run Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jakobbotsch]

@EgorBo I noticed that no arm64 results were summarized in the latest Fuzzlyn run because one of the partitions timed out (likely it was reducing an example past the timeout of 1.5 hours, might need to up it a bit or give up on reductions if we are getting close to the timeout). But it looks like some examples were found, I extracted one from one of the partitions that weren't killed:

// Generated by Fuzzlyn v1.5 on 2021-12-12 18:21:13
// Run on Arm64 Linux
// Seed: 16712647819592322137
// Reduced from 55.7 KiB to 0.3 KiB in 00:09:53
// Debug: Outputs True
// Release: Outputs False
public class C0
{
    public sbyte F2;
}

public class Program
{
    public static void Main()
    {
        var vr2 = new C0();
        uint[, ] vr9 = new uint[, ]{{2451056371U}};
        bool vr10 = vr2.F2-- <= vr9[0, 0];
        System.Console.WriteLine(vr10);
    }
}

[EgorBo]

/azp run Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[EgorBo]

/azp run Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[EgorBo]

@dotnet/jit-contrib PTAL, very simple change with nice diffs (up to -44376)

[EgorBo]

dead code

[BruceForstall]

1. Please update the IsRedundantMov function header comment to cover this new case.
2. Did you look at why we're generating the extraneous mov in the first place? I.e., is it easy/possible to simply stop generating it instead of cleaning it up later?

[EgorBo]

Did you look at why we're generating the extraneous mov in the first place? I.e., is it easy/possible to simply stop generating it instead of cleaning it up later?

Yes it's possible via a sort of an invalid LIR:

N004 (  5,  5) [000003] ---XG-------              *  RETURN    long   $280
N003 (  4,  4) [000002] ---XG----U--              \--*  CAST      long <- ulong <- uint <l:$241, c:$243>
N002 (  3,  2) [000001] *--XG-------                 \--*  IND       int    <l:$201, c:$200>
N001 (  1,  1) [000000] ------------                    \--*  LCL_VAR   byref  V00 arg0         u:1 (last use) $80

N004 (  5,  5) [000003] ---XG-------              *  RETURN    long   $280
N002 (  3,  2) [000001] *--XG-------               \--*  IND       int    <l:$201, c:$200>
N001 (  1,  1) [000000] ------------                  \--*  LCL_VAR   byref  V00 arg0         u:1 (last use) $80

or via a new GT_IND_x node but it doesn't bring much value compared to this change IMO.

but I'd keep it in the emitter (it's a few lines of code anyway) rather than producing sub-valid IR in lower. It's just like ldr cleared upper 4 bytes for us unintentionally 🙂

[EgorBo]

Please update the IsRedundantMov function header comment to cover this new case.

Done!

[kunalspathak]

LGTM