Optimize AdvSimd.Extract() when passed variable that can be const propagated

[kunalspathak]

public byte DoExtract(Vector64<byte> vector) {
  int index = 5;
  AdvSimd.Extract(vector, index);
}

I was expecting it to generate:

G_M20657_IG02:
        3DC007B0          ldr     q16, [fp,#16]
        0E0B3E00          umov    w0, v16.b[5]

But instead we generate the following.

G_M20657_IG02:
        3DC007A0          ldr     q0, [fp,#16]
        528000A0          mov     w0, #5
        97FFF7F5          bl      System.Runtime.Intrinsics.Arm.AdvSimd:Extract(System.Runtime.Intrinsics.Vector128`1[Byte],ubyte):ubyte
        53001C00          uxtb    w0, w0

It happens because we decide whether to fallback or not depending on the index operand. If it is const, we generate the optimize code however this decision happens during importing and we won't know if the operand is constant or not until we do constant propagation which is in later phase.

We should also investigate if there are more scenarios in which we miss optimizing opportunity because of this dependency and evaluate if we should do the decision after constant propagation is done probably in lower.

category:cq
theme:hardware-intrinsics
skill-level:intermediate
cost:medium

[kunalspathak]

//cc : @BruceForstall , @echesakovMSFT , @tannergooding

[BruceForstall]

cc @CarolEidt

[echesakov]

This is a case for any intrinsic that has an immediate operand - not only for Extract
I wonder if it's possible to move an intrinsic call transofrmation from importer to a later phase.

[EgorBo]

Doesn't Roslyn propagate constants for such simple cases (without inlining) ?

[tannergooding]

This is basically a dupe of #11062 and possibly a couple other issues iirc. It is a problem on both x86/x64 and ARM64.

Ideally we would delay the decision for this to be a call or constant until lowering but that isn't necessarily "easy" to do today.
We already have minimal support for rewriting intrinsics to calls in Rationalization (which happens just before lowering) and are using that today for GT_INTRINSIC.

We could presumably extend that to GenTreeJitIntrinsic as well, but it would require a few changes including making it a LARGE_NODE.
I left some comments from my initial investigation here: #11062 (comment) including some of the issues I ran into with the RwriteIntrinsicAsUserCall method.

[tannergooding]

There is also another case that might be related where we miss some optimizations on x86 due to GT_CAST nodes: #35857 (comment)

Basically the tree might look like:

               [000038] -----+------                 +--*  CAST      int <- ubyte <- int
               [000000] -----+------                 |  \--*  LCL_VAR   int    V01 arg0

and certain instructions might be able to contain or consume the underlying value directly, but we aren't smart enough to contain and handle the cast today.

[BruceForstall]

Since it appears unlikely we will work on this for 5.0, I've moved it out to 6.0.

cc @AndyAyersMS who might be interested in the phase ordering aspect of this.