JIT: Fold "shift-by-zero" in lower

[EgorBo]

Fixes a Checked-only assert found in #61209 by Fuzzlyn.

cc @jakobbotsch

A few diffs:

Top file improvements (bytes):
-4 : 87027.dasm (-1.23% of base)
-4 : 87338.dasm (-3.70% of base)
-4 : 88327.dasm (-6.25% of base)
-4 : 88191.dasm (-5.26% of base)
4 total files with Code Size differences (4 improved, 0 regressed), 0 unchanged.
Top method improvements (bytes):
-4 (-6.25% of base) : 88327.dasm - DevDiv_534476.ILGEN_CLASS:ILGEN_METHOD(long):float
-4 (-3.70% of base) : 87338.dasm - GitHub_18291:ILGEN_METHOD(long,byte,long):ushort
-4 (-5.26% of base) : 88191.dasm - ILGEN_0x1f290143:Method_0x8252f06e(double,ushort,int,ubyte,float,long,int,long):int
-4 (-1.23% of base) : 87027.dasm - ILGEN_CLASS:ILGEN_METHOD(ubyte,long,int):long
Top method improvements (percentages):
-4 (-6.25% of base) : 88327.dasm - DevDiv_534476.ILGEN_CLASS:ILGEN_METHOD(long):float
-4 (-5.26% of base) : 88191.dasm - ILGEN_0x1f290143:Method_0x8252f06e(double,ushort,int,ubyte,float,long,int,long):int
-4 (-3.70% of base) : 87338.dasm - GitHub_18291:ILGEN_METHOD(long,byte,long):ushort
-4 (-1.23% of base) : 87027.dasm - ILGEN_CLASS:ILGEN_METHOD(ubyte,long,int):long

e.g. https://www.diffchecker.com/oEoe5xQk

[ghost]

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

Issue Details

---

Fixes a Checked-only assert found in #61209 by Fuzzlyn.

cc @jakobbotsch

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

[SingleAccretion]

Do I understand correctly this is the fix and the removal of nop shifts is a separate optimization, or is that required as well?

FWIW, I would prefer we not do these ad-hoc opts in lowering (instead tracing back the where the frontend "failed at its job" and so on).

[EgorBo]

@SingleAccretion it's pretty normal to duplicate peepholes accross phases and we already do it. Front-end didn't fail here, only rationalizer managed to fold this:

N036 ( 47, 59) [000024] -ACXG------- \--* LSH int <l:$2c8, c:$2d2>
N035 ( 2, 5) [000067] -A--G------- \--* COMMA int N033 ( 1, 3) [000042] -A--G---R--- +--* ASG ref <l:$1c2, c:$1d5>
N032 ( 1, 1) [000041] D------N---- | +--* LCL_VAR ref V02 tmp2 d:1 <l:$280, c:$85>
N031 ( 1, 1) [000060] ------------ | \--* LCL_VAR ref V03 cse0 u:1 <l:$280, c:$81>
N034 ( 1, 2) [000066] ------------ \--* CNS_INT int 0 <l:$2d1, c:$2d0>

into

N033 ( 1, 3) [000042] DA--G------- * STORE_LCL_VAR ref V02 tmp2 d:1
N034 ( 1, 2) [000066] ------------ t66 = CNS_INT int 0 <l:$2d1, c:$2d0>
/--* t9 int +--* t66 int N036 ( 47, 59) [000024] ---XG------- t24 = * LSH int <l:$2c8, c:$2d2>
/--* t24 int N037 ( 48, 60) [000025] ---XG------- * RETURN int $107

[EgorBo]

maybe some day we'll get a DSL for transformations which will be compiled into morph and lower at the same time (that's how some C++ compilers work today)

[jakobbotsch]

Is it really worth to add this optimization in lower that only has hits in fuzzer generated code?

[EgorBo]

@jakobbotsch not really, but the diff found 4 more cases and we still don't have collections for real-world apps to judge. but let me remove it since it raised concerns by you two

[EgorBo]

PTAL