Stop generating CLS_VAR for 64 bit targets

[SingleAccretion]

This is the first change that fully disables CLS_VAR - on 64 bit platforms. The reason I am doing it this way is because there will be many more (positive) diffs on x86, and ARM likely requires some CSE heuristic changes and/or quirks to avoid some regressions.

We are not expecting diffs on ARM64. But expecting some limited amount of them on x64, caused by:

1. "Hoisting" more constants (Do not hoist constants if they will not be CSEed #64039).
2. Slightly different gtSetEvalOrder behavior: more aggressive reversal of ASG(..., IND(static addr)) (it didn't reverse for leaf CLS_VAR RHSs).
3. Very subtle changes in register allocation due to more opportunities for reuse of constants.

At first, my goal was to make this a zero-diff change, by mititigating all the above ("and more") with other changes, but after some weeks of looking at the problems from different angles, I "gave up" and decided it would be more productive to accept the diffs.

Diffs.

[ghost]

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

Issue Details

---

This is the first change that fully disables CLS_VAR - on 64 bit platforms. The reason I am doing it this way is because there will be many more (positive) diffs on x86, and ARM likely requires yet one more change to CSE heuristics and/or quirks to avoid some regressions.

We are not expecting diffs on ARM64, and expecting some limited diffs on x64, due to the fact we will now be "hoisting" more constants (#64039).

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[SingleAccretion]

Actually fewer diffs than I initially feared, very nice (and green CI!).

@dotnet/jit-contrib - the simple part of deleting CLS_VAR.

[jakobbotsch]

Nice! Do you plan to delete CLS_VAR in another change?

[SingleAccretion]

Yes, there will be at least the x86 change and the ARM change (probably the latter one will actually delete the code).