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
