aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/trans-array.h
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2021-09-25 13:02:21 +0200
committerAldy Hernandez <aldyh@redhat.com>2021-09-27 11:43:19 +0200
commite1d01f4973eee8d229ddc326ff7c3bd5f4cf32c1 (patch)
tree99f4153689b443117912c1904133000de63d8122 /gcc/fortran/trans-array.h
parent6390c5047adb75960f86d56582e6322aaa4d9281 (diff)
downloadgcc-e1d01f4973eee8d229ddc326ff7c3bd5f4cf32c1.zip
gcc-e1d01f4973eee8d229ddc326ff7c3bd5f4cf32c1.tar.gz
gcc-e1d01f4973eee8d229ddc326ff7c3bd5f4cf32c1.tar.bz2
Convert some evrp uses in DOM to the range_query API.
DOM is the last remaining user of the evrp engine. This patch converts a few uses of the engine and vr-values into the new API. There is one subtle change. The call to vr_value's op_with_constant_singleton_value_range can theoretically return non-constants, unlike the range_query API which only returns constants. In this particular case it doesn't matter because the symbolic stuff will have been handled by the const_and_copies/avail_exprs read in the SSA_NAME_VALUE copy immediately before. I have verified this is the case by asserting that all calls to op_with_constant_singleton_value_range at this point return either NULL or an INTEGER_CST. Tested on x86-64 Linux with a regstrap, as well as the aforementioned assert. gcc/ChangeLog: * gimple-ssa-evrp-analyze.h (class evrp_range_analyzer): Remove vrp_visit_cond_stmt. * tree-ssa-dom.c (cprop_operand): Convert to range_query API. (cprop_into_stmt): Same. (dom_opt_dom_walker::optimize_stmt): Same.
Diffstat (limited to 'gcc/fortran/trans-array.h')
0 files changed, 0 insertions, 0 deletions