aboutsummaryrefslogtreecommitdiff
path: root/gcc/c-family/c-cppbuiltin.cc
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2022-09-23 19:47:19 +0200
committerAldy Hernandez <aldyh@redhat.com>2022-09-26 19:24:58 +0200
commit5e77d4082fa845f1182641a93cfbae71984244d2 (patch)
tree03e512623a485bab33c1b2764e95237525ce5384 /gcc/c-family/c-cppbuiltin.cc
parentbe4b32b9ef69b86b662cb7511b48cd1048a55403 (diff)
downloadgcc-5e77d4082fa845f1182641a93cfbae71984244d2.zip
gcc-5e77d4082fa845f1182641a93cfbae71984244d2.tar.gz
gcc-5e77d4082fa845f1182641a93cfbae71984244d2.tar.bz2
Optimize [0 = x & MASK] in range-ops.
For [0 = x & MASK], we can determine that x is ~MASK. This is something we're picking up in DOM thanks to maybe_set_nonzero_bits, but is something we should handle natively. This is a good example of how much easier to maintain the range-ops entries are versus the ad-hoc pattern matching stuff we had to do before. For the curious, compare the changes to range-op here, versus maybe_set_nonzero_bits. I'm leaving the call to maybe_set_nonzero_bits until I can properly audit it to make sure we're catching it all in range-ops. It won't hurt, since both set_range_info() and set_nonzero_bits() are intersect operations, so we'll never lose information if we do both. PR tree-optimization/107009 gcc/ChangeLog: * range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x & MASK. (range_op_bitwise_and_tests): New test.
Diffstat (limited to 'gcc/c-family/c-cppbuiltin.cc')
0 files changed, 0 insertions, 0 deletions