public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Richard Biener <rguenther@suse.de>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Tame path_range_query::compute_imports
Date: Thu, 11 Aug 2022 09:59:43 -0400	[thread overview]
Message-ID: <bb0e1a67-1937-4427-3e02-9e71ef061311@redhat.com> (raw)
In-Reply-To: <73820.122081107421800679@us-mta-533.us.mimecast.lan>


On 8/11/22 07:42, Richard Biener wrote:
> This avoids going BBs outside of the path when adding def chains
> to the set of imports.  It also syncs the code with
> range_def_chain::get_def_chain to not miss out on some imports
> this function would identify.
>
> Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
>
> The question still stands on what the path_range_query::compute_ranges
> actually needs in its m_imports - at least I don't easily see how
> the range-folds will use the path range cache or be path sensitive
> at all.

All the range folding code is in gimple_range_fold.{h,cc}, and its 
driven by the mystical FUR_source classes.  fur_source stands for 
Fold_Using_Range source, and its basically just an API class which all 
the folding routines use to make queries. it is used by all the fold 
routines to ask any questions about valueizing relations,  ssa name, 
etc..   but abstracts the actual source of the information. Its the 
distillation from previous incarnations where I use to pass an edge, a 
stmt and other stuff to each routine that it might need, and decided to 
abstract since it was very unwieldy.  The base class requires only a 
range_query which is then used for all queries.

Then I derive fur_stmt which is instantiated additionally with the stmt 
you wish to fold at, and it will perform queries using that stmt as the 
context source..   Any requests for ranges/relations/etc will occur as 
if that stmt location is the source.  If folding a particular stmt, you 
use that stmt as the fur_stmt source.  This is also how I do 
recalculations..  when we see
bb4:
   a_32 = f_16 + 10
<...>
bb88:
   if (f_16 < 20)
      b_8 = a_32 + 8
and there is sufficient reason to think that a_32 would have a different 
value , we can invoke a re-fold of a_32's defintion stmt at the use 
point in b_8..  using that stmt as the fur_source. Ranger will take into 
account the range of f_16 being [0,19] at that spot, and recalculate 
a_32 as [10,29].  Its expensive to do this at every use point, so we 
only do it if we think there is a good reason at this point.

The point is that the fur_source mechanism is how we provide a context, 
and that class talkes care of the details of what the source actually is.

There are other fur_sources.. fur_edge allows all the same questions to 
be answered, but using an edge as the source. Meaning we can calculate 
an arbitrary stmt/expressions as if it occurs on an edge.

There are also a couple of specialized fur_sources.. there is an 
internal one in ranger which communicates some other information called 
fur_depend which acts like range_of_stmt, but with additional 
functionality to register dependencies in GORI as they are seen.

Aldy overloads the fur_depend class (called jt_fur_source--  Im not sure 
the origination of the name) to work with the values in the path_query 
class.   You will note that the path_range_query class inherits from a 
range_query, so it supports all the range_of_expr, range_of_stmt, and 
range_on_edge aspect of rangers API.

I believe all attempts are first made to pick up the value from the path 
cache, and failing that, a query is made from ranger at the start of the 
path.  So as the walk thru the path happens, and edges are taken/chosen, 
all the context information local to the path should be placed into the 
path cache, and used in any future queries using the path_range_query.  
Ranger will only be invoked if there is no entry in the path query, and 
it would provide the range as it would appear at entry to the path.

Thats my high level understanding of how the path_query class provides 
context.

So I think to answer the other question, the m_imports list Is probably 
the list of ssa-names that may have relevant context information which 
the path_query would provide ranges during the walk instead of ranger?  
I think Aldy pre-calculates all those during the walk, and then uses 
this pre-filled cache to answer questions at the thread exit?   Thats my 
guess

> K?
>
> Thanks,
> Richard.
>
> 	* gimple-range-path.cc (path_range_query::compute_imports):
> 	Restrict walking SSA defs to blocks inside the path.  Track
> 	the same operands as range_def_chain::get_def_chain does.
> ---
>   gcc/gimple-range-path.cc | 39 ++++++++++++++++++++++++++++-----------
>   1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
> index 5ae374df3a2..5ff2c733b4e 100644
> --- a/gcc/gimple-range-path.cc
> +++ b/gcc/gimple-range-path.cc
> @@ -575,18 +575,11 @@ path_range_query::compute_imports (bitmap imports, const vec<basic_block> &path)
>       {
>         tree name = worklist.pop ();
>         gimple *def_stmt = SSA_NAME_DEF_STMT (name);
> +      if (SSA_NAME_IS_DEFAULT_DEF (name)
> +	  || !path.contains (gimple_bb (def_stmt)))
> +	continue;
>   
> -      if (is_gimple_assign (def_stmt))
> -	{
> -	  add_to_imports (gimple_assign_rhs1 (def_stmt), imports);
> -	  tree rhs = gimple_assign_rhs2 (def_stmt);
> -	  if (rhs && add_to_imports (rhs, imports))
> -	    worklist.safe_push (rhs);
> -	  rhs = gimple_assign_rhs3 (def_stmt);
> -	  if (rhs && add_to_imports (rhs, imports))
> -	    worklist.safe_push (rhs);
> -	}
> -      else if (gphi *phi = dyn_cast <gphi *> (def_stmt))
> +      if (gphi *phi = dyn_cast <gphi *> (def_stmt))
>   	{
>   	  for (size_t i = 0; i < gimple_phi_num_args (phi); ++i)
>   	    {
> @@ -599,6 +592,30 @@ path_range_query::compute_imports (bitmap imports, const vec<basic_block> &path)
>   		worklist.safe_push (arg);
>   	    }
>   	}
> +      else if (gassign *ass = dyn_cast <gassign *> (def_stmt))
> +	{
> +	  tree ssa[3];
> +	  if (range_op_handler (ass))
> +	    {
> +	      ssa[0] = gimple_range_ssa_p (gimple_range_operand1 (ass));
> +	      ssa[1] = gimple_range_ssa_p (gimple_range_operand2 (ass));
> +	      ssa[2] = NULL_TREE;
> +	    }
> +	  else if (gimple_assign_rhs_code (ass) == COND_EXPR)
> +	    {
> +	      ssa[0] = gimple_range_ssa_p (gimple_assign_rhs1 (ass));
> +	      ssa[1] = gimple_range_ssa_p (gimple_assign_rhs2 (ass));
> +	      ssa[2] = gimple_range_ssa_p (gimple_assign_rhs3 (ass));
> +	    }
> +	  else
> +	    continue;
> +	  for (unsigned j = 0; j < 3; ++j)
> +	    {
> +	      tree rhs = ssa[j];
> +	      if (rhs && add_to_imports (rhs, imports))
> +		worklist.safe_push (rhs);
> +	    }
> +	}
>       }
>     // Exported booleans along the path, may help conditionals.
>     if (m_resolve)


  parent reply	other threads:[~2022-08-11 13:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <73820.122081107421800679@us-mta-533.us.mimecast.lan>
2022-08-11 13:11 ` Aldy Hernandez
2022-08-11 13:59 ` Andrew MacLeod [this message]
2022-08-11 15:11   ` Aldy Hernandez
2022-08-15  9:53     ` Richard Biener
2022-08-16  8:56       ` Aldy Hernandez
2022-08-16  9:28         ` Richard Biener
2022-08-16 10:25       ` Aldy Hernandez
2022-08-16 11:38         ` Richard Biener
2022-08-16 12:17           ` Aldy Hernandez
2022-08-16 12:26             ` Richard Biener
2022-08-16 12:32               ` Aldy Hernandez
2022-08-16 13:47         ` Andrew MacLeod
2022-08-16 13:55           ` Aldy Hernandez
2022-08-16  8:21 ` Aldy Hernandez
2022-08-16  8:32   ` Richard Biener
2022-08-16  9:08     ` Aldy Hernandez
2022-08-16  9:15       ` Aldy Hernandez
2022-08-16  9:28         ` Richard Biener
2022-08-16 13:42           ` Andrew MacLeod
2022-08-17  1:16   ` [COMMITTED] Abstract interesting ssa-names from GORI Andrew MacLeod
2022-08-17  1:18     ` Andrew MacLeod
2022-08-18  7:26       ` Aldy Hernandez
2022-08-11 11:42 [PATCH] Tame path_range_query::compute_imports Richard Biener
  -- strict thread matches above, loose matches on Subject: below --
2022-08-11 11:42 Richard Biener
2022-08-11 11:42 Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb0e1a67-1937-4427-3e02-9e71ef061311@redhat.com \
    --to=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).