This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, As analyzed in PR71437, it's a missed PRE issue due to missed jump threading, and then due to inaccurate VRP information. In function extract_range_for_var_from_comparison_expr, we compute range for variable "a" under condition that comparison like "a <= limit" is true. It extracts limit's range information and set range [MIN, limit_vr->max] to var. This is inaccurate when limit_vr->max is MAX. In this case the final range computed is [MIN, MAX] which is VARYING. In fact, symbolic range info [MIN, limit] is better here. This patch fixes PR71437 by making such change. It also handles ">=" cases. Bootstrap and test on x86_64 and AArch64 finished. All tests are OK except test gcc.dg/tree-ssa/pr31521.c. I further investigated it and believe it's another missed optimization in VRP. Basically, operand_less_p is weak in handling symbolic value range. Given below value ranges: x: [1, INF+] a: [-INF, x - 1] b: [0, INF+] It doesn't know that "x - 1 < INF+" must be true, thus (intersect a b) is [0, x - 1]. I believe there may be other places in which symbolic value range is not handled properly. So any comment? Thanks, bin 2017-01-24 Bin Cheng <bin.cheng@arm.com> PR tree-optimization/71437 * tree-vrp.c (extract_range_for_var_from_comparison_expr): Prefer symbolic range form if limit has no useful range information. gcc/testsuite/ChangeLog 2017-01-24 Bin Cheng <bin.cheng@arm.com> PR tree-optimization/71437 * gcc.dg/tree-ssa/pr71437.c: New test.
Attachment:
pr71437-20170123.txt
Description: pr71437-20170123.txt
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |