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]

[PATCH PR71437]Prefer symbolic range bound if the var doesn't have useful range.


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]