Use the maskBaseType when consuming a mask directly as part of KORTEST #104364
+37
−7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This resolves #104317.
The issue had been that we were eliding
ConvertMaskToVectorwithout accounting for the fact that there could have been a change of thebaseTypesuch as caused by usingvalue.AsInt32(). We normally do take this into account, there was just an existing path in lowering that missed this and which was now being hit due to recent IR improvements.An example of where this is problematic would be if we had a
TYP_LONGmask of0b10, theConvertVectorToMaskwould produce[Zero, AllBitsSet], if that were then consumed by an operation taking aTYP_INTit would see it as[Zero, Zero, AllBitsSet, AllBitsSet]. However, if we consumed it directly as a mask we'd still have10when the API would've needed0b1100for parity.However, some of the use sites we can still elide the
ConvertMaskToVector, we just need to fixup the consumer to have the right base type. For example, if we're doingop_EqualityagainstZeroorAllBitsSet, then the bitset expected never changes. The same applies forCndSelwhich is a bitwise operation.