aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-ssa-threadbackward.c
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2021-09-03 10:01:25 +0200
committerAldy Hernandez <aldyh@redhat.com>2021-09-03 18:40:02 +0200
commit8af8abfbbace49e6e5e9413d4e661533437106a0 (patch)
tree987311974970cb0b1c6f1e304dfa205995ff3f75 /gcc/tree-ssa-threadbackward.c
parent47543e5f9d1fc502be79f91c87cbeb6eda17e641 (diff)
downloadgcc-8af8abfbbace49e6e5e9413d4e661533437106a0.zip
gcc-8af8abfbbace49e6e5e9413d4e661533437106a0.tar.gz
gcc-8af8abfbbace49e6e5e9413d4e661533437106a0.tar.bz2
Implement POINTER_DIFF_EXPR entry in range-op.
I've seen cases in the upcoming jump threader enhancements where we see a difference of two pointers that are known to be equivalent, and yet we fail to return 0 for the range. This is because we have no working range-op entry for POINTER_DIFF_EXPR. The entry we currently have is a mere placeholder to avoid ignoring POINTER_DIFF_EXPR's so adjust_pointer_diff_expr() could get a whack at it here: // def = __builtin_memchr (arg, 0, sz) // n = def - arg // // The range for N can be narrowed to [0, PTRDIFF_MAX - 1]. This patch adds the relational magic to range-op, which we can just steal from the minus_expr code. gcc/ChangeLog: * range-op.cc (operator_minus::op1_op2_relation_effect): Abstract out to... (minus_op1_op2_relation_effect): ...here. (class operator_pointer_diff): New. (operator_pointer_diff::op1_op2_relation_effect): Call minus_op1_op2_relation_effect. (integral_table::integral_table): Add entry for POINTER_DIFF_EXPR.
Diffstat (limited to 'gcc/tree-ssa-threadbackward.c')
0 files changed, 0 insertions, 0 deletions