Applied slight tweak to the patch for the gcc12 branch.

botstrapped and no regressions on x86_64-pc-linux-gnu.  Pushed.

Andrew

-------- Forwarded Message --------
Subject: 	[COMMITTED] PR tree-optimization/106114 - Don't use gori 
dependencies to optimize.
Date: 	Wed, 29 Jun 2022 21:40:44 -0400
From: 	Andrew MacLeod <amacleod@redhat.com>
To: 	gcc-patches <gcc-patches@gcc.gnu.org>
CC: 	Aldy Hernandez <aldyh@redhat.com>



The routine which tried to fold and's and or's using relations was using 
the dependency cache as a shortcut to determine if there were 2 ssa 
names on the feeding expressions, and assuming that was correct.

ie

   _16 = a.0_1 < -117;
   _17 = a.0_1 >= -83;
   _18 = _16 | _17;

the dependency cache indicates that a.0_1 is "ssa1" dependency for _16 
and also for _17.  we dont have to scan the statement, so temporal out 
of date info is very quick.

Its also not meant to reflect that actual statement.. ie, it can get out 
of date.  Not is a way that makes anything incorrect, but in a way that 
may possibly result in a  either a missed opportunity or slightly more 
work when statements are being rewritten on the fly..  ie  DOM rewrites 
that to:

   _16 = a.1_15 < -117;
   _17 = a.1_15 >= -83;
   _18 = _16 | _17;

When fold_using_range is later invoked, a.1_15 is added a dependency to 
_16 and _17,  not attempting to understand that its a replacement, we 
simply now think that both a.0_1 and a.1_15 are dependencies.  so if 
either one becomes out of date, then ranger will recalculate _16 and/or _17

fold_using_range::relation_fold_and_or was using thet dependency cache 
as if it represent the operands of the statement accurately... so after 
the DOM rewrite, it thought that there were 2 operands on the _16 and 
_17 expression, the 2 dependencies in the cache, misconstruing it as

   _16 = a.0_1_ < a.1_15;
   _17 = a.0_1 >= a.1_15;
   _18 = _16 | _17;

Thus it thought is could fold it away.


The dependency cache shortcut should NOT be used for optimizations.   
THis patch correct the problem, and simply looks at the 2 operands of 
the feeding instructions.

bootstrapped on build-x86_64-pc-linux-gnu with no regressions. Pushed.

This is less likely to occur in GCC12 since there is less IL change on 
the fly, but it should be safe to make this change just in case.  OK for 
GCC12?

Andrew

PS. and yes, it fixes the other 2 testcases as well.