[X86] add missing TP and latency information for `rcl_N/rcr_N`

[Ruihan-Yin]

https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/emitxarch.cpp#L18813

As of now, JIT does not have the throughput and latency information rcl_N and rcr_N, we will need to add these information to make sure the instructions are properly emitted and measured when they are used.

As of now, I don't run into any issue with this in testing, so it means rcl_N/rcr_N may not be used at all now, and might indicate some optimization for rotation might be missing. This part may need further investigation.

[dotnet-policy-service]

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

[Ruihan-Yin]

https://uops.info/html-instr/RCR_R32_I8.html#SKL
https://uops.info/html-instr/RCL_R32_I8.html#SKL

Looking at how INS_rcr/INS_rcl (the CL variation) are defined in JIT now, I would suppose it should be fine to use the same tp/latency data for INS_rcr_N/INS_rcl_N if we want a rough estimation. While there are some variation from the experiment, I wonder how we usually handle this.

[tannergooding]

We normally just use the average number reported on the main https://uops.info/table.html page for the Skylake Architecture (or official latency information page for Intel/AMD)

In this case, RCL reg, cl is reported as [5; 8] while RCL reg, 1 is reported 2 and RCL reg, imm8 is reported [5; 6].

We could optionally special case the imm8 == 1 case to track as 2 but otherwise it seems like it has the same general latency as the non-immediate version and should be averaged at 6 cycles.

[Ruihan-Yin]

Thanks! I will submit a PR after the main REX2 encoding PR gets merged.