JIT: Mark swift error as busy before call definition RefPosition

[jakobbotsch]

The RefPosition we were inserting here was inserted too late to actually protect the call definition from being allocated into the error register.

Instead, we can just mark the existing RefTypeFixedReg created for the argument use as delay freed, which will have the intended effect of keeping the error register busy until after the call definition.

Noticed this while looking at the RefPositions in #101760 (comment).

[dotnet-policy-service]

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

[jakobbotsch]

TP differences are because of inlining decision changes. No longer calling newRefPosition leads to MSVC not inlining it anymore in some other places.

Base: 15869486520, Diff: 15875365069, +0.0370%

17470572  : NA      : 51.20% : +0.1101% : private: class RefPosition * __cdecl LinearScan::newRefPosition(enum _regNumber_enum, unsigned int, enum RefType, struct GenTree *, unsigned __int64)          
2470255   : +3.51%  : 7.24%  : +0.0156% : public: void __cdecl LinearScan::buildIntervals<1>(void)                                                                                                       
-816037   : -15.06% : 2.39%  : -0.0051% : private: void __cdecl LinearScan::buildUpperVectorRestoreRefPosition(class Interval *, unsigned int, struct GenTree *, bool, unsigned int)                     
-13290980 : -10.92% : 38.95% : -0.0838% : private: class RefPosition * __cdecl LinearScan::newRefPosition(class Interval *, unsigned int, enum RefType, struct GenTree *, unsigned __int64, unsigned int)

We expect these decisions to be significantly altered by native PGO anyway, so I don't see much point in making any changes here.

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @amanasifkhalid @kunalspathak

[amanasifkhalid]

LGTM -- might be a good idea to run outerloop and/or jitstressregs (I think I remember the latter exposing a case where LSRA would try to use the error register to hold the Swift call's address). Thanks!

[jakobbotsch]

/azp run runtime-coreclr outerloop, runtime-coreclr jitstressregs

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jakobbotsch]

Failures are #99810 and #101721