diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2021-09-03 10:01:25 +0200 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2021-09-03 18:40:02 +0200 |
commit | 8af8abfbbace49e6e5e9413d4e661533437106a0 (patch) | |
tree | 987311974970cb0b1c6f1e304dfa205995ff3f75 /gcc/tree-ssa-threadbackward.c | |
parent | 47543e5f9d1fc502be79f91c87cbeb6eda17e641 (diff) | |
download | gcc-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