Improve branch optimizer around implied relops

[EgorBo]

Should help with cases like:

void Test(int x) { if (x > 100) if (x > 10) // always true Console.WriteLine(); }

; Method Program:Test(int):this (FullOpts) sub rsp, 40 cmp edx, 100 jle SHORT G_M52364_IG04 - cmp edx, 10 - jle SHORT G_M52364_IG04 call [System.Console:WriteLine()] G_M52364_IG04: nop add rsp, 40 ret -; Total bytes of code: 26 +; Total bytes of code: 21

Ideally, it should be done in "redundant branch opt" phase, but it seems to be way more complicated so at least let's have it in assertprop for now: EgorBo@cdbaac0

[ghost]

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

Issue Details

---

Should help with cases like:

void Test(int x) { if (x > 100) if (x > 10) // always true Console.WriteLine(); }

Ideally, it should be done in "redundant branch opt" phase, but it seems to be way more complicated so at least let's have it in assertprop for now.

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

[EgorBo]

/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[EgorBo]

PTAL @AndyAyersMS @dotnet/jit-contrib

Diffs (not too big but I have some follow-up ideas how to extend them)

[AndyAyersMS]

The reversal/negation here is a bit tricky, but I think I follow it.

Seems like there's a complementary case where you don't negate the upper relop and then may instead have canInferFromTrue abilities?

[EgorBo]

Yeah, basically there are two cases:

canInferFromFalse:

if (x > 100) { if (x > 10) { ... } }

canInferFromTrue:

if (x > 100) { ... } if (x > 10) { ... }

I'll check separately the 2nd case (last I tried it added very little diffs)

[danmoseley]

(not too big but I have some follow-up ideas how to extend them

How many of those diffs represent places code itself should be cleaned up? Like your example.

[EgorBo]

(not too big but I have some follow-up ideas how to extend them

How many of those diffs represent places code itself should be cleaned up? Like your example.

I inspected a few diffs and they were inlining-related so I wasn't able to find an obvious case that can be cleaned up in C#

[EgorBo]

Hm.. arm failures look related and they're floating point related... soft floats?

[EgorBo]

Since the last review I found a small bug - I replaced ssize_t with target_ssize_t (Linux arm failed on CI and it was the only target where we generate R2R'd code for corelib using 64bit jit for it via crosscompilation).