public inbox for
 help / color / mirror / Atom feed
From: Andrew MacLeod <>
To: Richard Biener <>,
	Jeff Law <>
Subject: Re: [PATCH] PR tree-optimization/109417 - Check if dependency is valid before using in may_recompute_p.
Date: Mon, 24 Apr 2023 09:51:15 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 4/11/23 05:21, Richard Biener via Gcc-patches wrote:
> On Wed, Apr 5, 2023 at 11:53 PM Jeff Law via Gcc-patches
> <> wrote:
>> On 4/5/23 14:10, Andrew MacLeod via Gcc-patches wrote:
>>> When a statement is first processed, any SSA_NAMEs that are dependencies
>>> are cached for quick future access.
>>> if we ;later rewrite the statement (say propagate a constant into it),
>>> its possible the ssa-name in this cache is no longer active.   Normally
>>> this is not a problem, but the changed to may_recompute_p forgot to take
>>> that into account, and was checking a dependency from the cache that was
>>> in the SSA_NAME_FREE_LIST. It thus had no SSA_NAME_DEF_STMT when we were
>>> expecting one.
>>> This patch simply rejects dependencies from consideration if they are in
>>> the free list.
>>> Bootstrapping on x86_64-pc-linux-gnu  and presuming no regressio0ns, OK
>>> for trunk?
>> eek.  So you've got a released name in the cache?  What happens if the
>> name gets released, then re-used?  Aren't you going to get bogus results
>> in that case?

Its not a real cache..  its merely a statement shortcut in dependency 
analysis to avoid re-parsing statements every time we look at them for 
dependency analysis

It is not suppose to be used for anything other than dependency 
checking.   ie, if an SSA_NAME changes, we can check if it matches 
either of the 2 "cached" names on this DEF, and if so, we know this name 
is stale.  we are never actually suppose to use the dependency cached 
values to drive anything, merely respond to the question if either 
matches a given name.   So it doesnt matter if the name here has been freed

> We never re-use SSA names from within the pass releasing it.  But if
> the ranger cache
> persists across passes this could be a problem.  See

This particular valueswould never persist beyond a current pass.. its 
just the dependency chains and they would get rebuilt every time because 
the IL has changed.

> flush_ssaname_freelist which
> for example resets the SCEV hash table which otherwise would have the
> same issue.
> IIRC ranger never outlives a pass so the patch should be OK.
> _But_ I wonder how ranger gets at the tree SSA name in the first place - usually
> caches are indexed by SSA_NAME_VERSION (because that's cheaper and

Its stored when we process a statement the first time when building 
dependency chains.  All comparisons down the road for 
staleness/dependency chain existence are against a pointer.. but we 
could simple change it to be an "unsigned int",  we'd then just have to 
compare again SSA_NAME_VERSION(name) instead..

> better than a pointer to the tree) and ssa_name (ver) will return NULL
> for released
> SSA names.  So range_def_chain::rdc could be just
>    struct rdc {
>     int ssa1;           // First direct dependency
>     int ssa2;           // Second direct dependency
>     bitmap bm;           // All dependencies
>     bitmap m_import;
>    };
> and ::depend1 return ssa_name (m_def_chain[v].ssa1) and everything woul
if the ssa-name is no longer in existence, does ssa_name (x) it return 
> work automatically (and save 8 bytes of storage).
> Richard.

>> jeff

  reply	other threads:[~2023-04-24 13:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 20:10 Andrew MacLeod
2023-04-05 21:52 ` Jeff Law
2023-04-11  9:21   ` Richard Biener
2023-04-24 13:51     ` Andrew MacLeod [this message]
2023-04-25  7:17       ` Richard Biener
2023-04-26  2:34       ` Jeff Law
2023-04-26 19:26         ` [COMMITTED 1/5] PR tree-optimization/109417 - Don't save ssa-name pointer in dependency cache Andrew MacLeod
2023-04-06 10:38 ` [PATCH] PR tree-optimization/109417 - Check if dependency is valid before using in may_recompute_p Jakub Jelinek

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:

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

  git send-email \ \ \ \ \ \

* 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).