JIT: Fix double handling of call operands when importing intrinsic #96557
Conversation
Some intrinsics can be a noop when they are imported. For example, `Unsafe.BitCast<T, T>(X)` just returns its operand when importing. If that operand is a call then we will run the tail logic of call importation for that call node twice, since that logic tries to filter out intrinsic importation with an `IsCall()` check. Switch the check to be based on `!bIntrinsicImported` instead. Fix dotnet#96461
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsSome intrinsics can be a noop when they are imported. For example, Fix #96461
|
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS |
|
|
||
| if (call->IsCall()) | ||
| // Sometimes "call" is not a GT_CALL (if we imported an intrinsic that didn't turn into a call) | ||
| if (!bIntrinsicImported) |
There was a problem hiding this comment.
Is this something that needs backported?
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
There was a problem hiding this comment.
Seems likely this double-processing ended up with the same result, so didn't actually cause a bug.
There was a problem hiding this comment.
I don't think it needs to be backported, I think it's very hard for the code that runs twice here to cause problems in release builds. Also we need a customer report for backporting.
Looks like it's been a potential issue for a long time, although it's unclear to me why we're only just seeing this "now" given how widely used intrinsics have been, including in potentially tail recursive positions, and we've many that can be no-ops or just return one of the input operands (such as op_UnaryPlus, AsInt32, etc).
Presumably people do not write code that involves noop intrinsics like op_UnaryPlus very often, and even more rarely that also satisfies the other conditions to hit the bug.
-- Notably looks like there are some asserts in this block checking that !bIntrinsicImported that can potentially be removed.
Let me address that as part of a future PR to rerunning CI.
Some intrinsics can be a noop when they are imported. For example,
Unsafe.BitCast<T, T>(X)just returns its operand when importing. Ifthat operand is a call then we will run the tail logic of call
importation for that call node twice, since that logic tries to filter
out intrinsic importation with an
IsCall()check. Switch the check tobe based on
!bIntrinsicImportedinstead.Fix #96461