JIT: Add more specific range assertion for bitwise and/or#120980
JIT: Add more specific range assertion for bitwise and/or#120980adamperlin merged 10 commits intodotnet:mainfrom
and/or#120980Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
and with 0, 1and with 0, 1
and with 0, 1and/or
There was a problem hiding this comment.
Pull Request Overview
This PR enhances the integral range analysis in the JIT compiler's assertion propagation to improve range inference for bitwise AND (GT_AND) and OR (GT_OR) operations, as well as non-negative constant values (GT_CNS_INT). These improvements enable better optimization opportunities by providing more precise range information.
- Adds range computation for
GT_ANDoperations considering when operands are non-negative - Adds range computation for
GT_ORoperations when both operands are non-negative - Extends
GT_CNS_INThandling to recognize all non-negative constants (not just 0 and 1)
|
There are a few interesting regressions here in some numeric operators like @@ -17,14 +17,15 @@
G_M24733_IG01: ; bbWeight=1, gcrefRegs=0000 {}, byrefRegs=0000 {}, byref, nogc <-- Prolog IG
;; size=0 bbWeight=1 PerfScore 0.00
G_M24733_IG02: ; bbWeight=1, gcrefRegs=0000 {}, byrefRegs=0000 {}, byref
- and ecx, edx
movzx rax, cl
- ;; size=5 bbWeight=1 PerfScore 0.50
+ movzx rcx, dl
+ and eax, ecx
+ ;; size=8 bbWeight=1 PerfScore 0.75
G_M24733_IG03: ; bbWeight=1, epilog, nogc, extend
ret
;; size=1 bbWeight=1 PerfScore 1.00
-; Total bytes of code 6, prolog size 0, PerfScore 1.50, instruction count 3, allocated bytes for code 6 (MethodHash=105b9f62) for method System.Byte:System.Numerics.IBitwiseOperators<System.Byte,System.Byte,System.Byte>.op_BitwiseAnd(byte,byte):byte (FullOpts)
+; Total bytes of code 9, prolog size 0, PerfScore 1.75, instruction count 4, allocated bytes for code 9 (MethodHash=105b9f62) for method System.Byte:System.Numerics.IBitwiseOperators<System.Byte,System.Byte,System.Byte>.op_BitwiseAnd(byte,byte):byte (FullOpts)
; ============================================================I investigated this some. The IL tree looks like this: Before, the Now this new optimization lets us remove the outermost cast in this case, but two inner two casts of the LCL_VAR nodes aren't removed, so we have: I'm pretty sure this is what is accounting for the diff in cases like these. |
|
@EgorBo @tannergooding I think this one is ready for another look. I have opened issue #121384 to address the regression described above. After talking with Egor I decided not to add an |
|
/azp run Fuzzlyn |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Fuzzlyn failures seem expected, stemming from existing issues from previous runs as well as runtime async. |
|
/ba-g infrastructure issue with no specific error message |
This is an attempt to address #119962 by adding a new range assertion for
x & cnswhencnscan be determined to be within[0, 1]. Possible improvements are incoming to generalize this to other constants, as well as new possible assertions for bitwiseor.