yeah, sure. Its wasted memory. If we ever need it fro anything, it
could be added back in.
I'll add it to my next commit.
Thanks
Andrew
On 6/23/25 18:21, Martin Jambor wrote:
Hello,
On Thu, May 23 2024, Andrew MacLeod wrote:
This patch provides a basic oracle which doesn't do anything, but will
still respond when queried. This allows passes to avoid the NULL check
for an oracle pointer before they do anything, and results in a slight
speedup in VRP, and a slightly more significant 0.3% speedup in jump
threading..
It also unifies the register and query names to nor specify what is
already apparent in the parameters.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
From 2f80eb1feb3f92c7e9e57d4726ec52ca7d27ce92 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacl...@redhat.com>
Date: Tue, 30 Apr 2024 09:35:23 -0400
Subject: [PATCH 02/12] Move to an always available relation oracle.
This eliminates the need to check if the relation oracle pointer is NULL
before every call by providing a default oracle which does nothing.
REmove unused routines, and Unify register_relation method names.
* gimple-range-cache.cc (ranger_cache::dump_bb): Remove check for
NULL oracle pointer.
(ranger_cache::fill_block_cache): Likewise.
* gimple-range-fold.cc (fur_stmt::get_phi_operand): Likewise.
(fur_depend::fur_depend): Likewise.
(fur_depend::register_relation): Likewise, use qury_relation.
(fold_using_range::range_of_phi): Likewise.
(fold_using_range::relation_fold_and_or): Likewise.
* gimple-range-fold.h (fur_source::m_oracle): Delete. Oracle
can be accessed dirctly via m_query now.
* gimple-range-path.cc (path_range_query::path_range_query):
Adjust for oracle reference pointer.
(path_range_query::compute_ranges): Likewise.
(jt_fur_source::jt_fur_source): Adjust for no m_oracle member.
(jt_fur_source::register_relation): Do not check for NULL
pointer.
(jt_fur_source::query_relation): Likewise.
* gimple-range.cc (gimple_ranger::gimple_ranger): Adjust for
reference pointer.
* value_query.cc (default_relation_oracle): New.
(range_query::create_relation_oracle): Relocate from header.
Ensure not being added to global query.
(range_query::destroy_relation_oracle): Relocate from header.
(range_query::range_query): Initailize to default oracle.
(ange_query::~range_query): Call destroy_relation_oracle.
* value-query.h (class range_query): Adjust prototypes.
(range_query::create_relation_oracle): Move to source file.
(range_query::destroy_relation_oracle): Move to source file.
* value-relation.cc (relation_oracle::validate_relation): Delete.
(relation_oracle::register_stmt): Rename to register_relation.
(relation_oracle::register_edge): Likewise.
* value-relation.h (register_stmt): Rename to register_relation and
provide default function in base class.
(register_edge): Likewise.
(relation_oracle::query_relation): Provide default in base class.
(relation_oracle::dump): Likewise.
(relation_oracle::equiv_set): Likewise.
(default_relation_oracle): New extenal reference.
(partial_equiv_set, add_partial_equiv): Move to protected.
* value-relation.h (relation_oracle::validate_relation): Delete.
[...]
@@ -208,66 +208,6 @@ static const tree_code relation_to_code [VREL_LAST] = {
ERROR_MARK, ERROR_MARK, LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR, EQ_EXPR,
NE_EXPR };
-// This routine validates that a relation can be applied to a specific set of
-// ranges. In particular, floating point x == x may not be true if the NaN bit
-// is set in the range. Symbolically the oracle will determine x == x,
-// but specific range instances may override this.
-// To verify, attempt to fold the relation using the supplied ranges.
-// One would expect [1,1] to be returned, anything else means there is
something
-// in the range preventing the relation from applying.
-// If there is no mechanism to verify, assume the relation is acceptable.
-
-relation_kind
-relation_oracle::validate_relation (relation_kind rel, vrange &op1, vrange
&op2)
-{
- // If there is no mapping to a tree code, leave the relation as is.
- tree_code code = relation_to_code [rel];
This seems to have been the only use of the array relation_to_code which
we however still have around. Should it be removed too?
Thanks,
Martin
