On 02/14/2017 03:05 AM, Bin Cheng wrote:
Hi,
This is the second try fixing PR71437. The old version patch tried to fix
issue in VRP but it requires further non-trivial change in VRP, specifically,
to better support variable value ranges. This is not appropriate at stage 4.
Alternatively, this patch tries to fix issue by improving threading. It
additionally simplifies condition by using assertion conditions.
Bootstrap and test on x86_64 and AArch64. Is it OK?
Thanks,
bin
2017-02-13 Bin Cheng <bin.ch...@arm.com>
PR tree-optimization/71437
* tree-ssa-loop-niter.c (tree_simplify_using_condition): Only
expand condition if new parameter says so. Also change it to
global.
* tree-ssa-loop-niter.h (tree_simplify_using_condition): New
declaration.
* tree-ssa-threadedge.c (tree-ssa-loop-niter.h): New include file.
(simplify_control_stmt_condition_1): Simplify condition using
assert conditions.
gcc/testsuite/ChangeLog
2017-02-13 Bin Cheng <bin.ch...@arm.com>
PR tree-optimization/71437
* gcc.dg/tree-ssa/pr71437.c: New test.
So following up. We're not going to get anywhere using the ranges in
VRP. As Bin noted in the V1 patch, VRP prefers a useless range with
constant bounds when a symbolic range would be better. Thus the
callbacks into VRP are doomed to failure.
Bin's patch works around this by using the ASSERT_EXPRs to recover the
symbolic range. So it's a bit of a hack, but not a terrible one. If we
want to continue this path, we might still look for ways to avoid
simplify_using_condition.
One idea would be to go ahead and record the equivalence from the
ASSERT_EXPR into the expression hash table and use the expression hash
table to simplify the condition. We didn't have that ability in the
past, but should now after the refactorings from last year.
It's slightly related to some ideas I've got around tackling 78496.
I'm in/out of the office for until the 27th semi-randomly. I'll try to
poke at this while on the road.
Jeff
