On 9/29/21 11:28 AM, Jeff Law wrote:
On 9/29/2021 9:20 AM, Andrew MacLeod via Gcc-patches wrote:
On 9/29/21 4:43 AM, Richard Biener wrote:
On Tue, Sep 28, 2021 at 10:39 PM Andrew MacLeod
<amacl...@redhat.com> wrote:
On 9/28/21 7:50 AM, Richard Biener wrote:
On Wed, Sep 15, 2021 at 10:46 AM Martin Liška <mli...@suse.cz> wrote:
/* Unswitch single LOOP. NUM is number of unswitchings done;
we do not allow
@@ -269,6 +311,7 @@ tree_unswitch_single_loop (class loop *loop,
int num)
class loop *nloop;
unsigned i, found;
tree cond = NULL_TREE;
+ edge cond_edge = NULL;
gimple *stmt;
bool changed = false;
HOST_WIDE_INT iterations;
@@ -311,11 +354,12 @@ tree_unswitch_single_loop (class loop
*loop, int num)
bbs = get_loop_body (loop);
found = loop->num_nodes;
+ gimple_ranger ranger;
ISTR constructing/destructing ranger has a non-negligible overhead -
is it possible
to keep it live for a longer time (note we're heavily modifying
the CFG)?
There is some overhead.. right now we determine all the imports and
exports for each block ahead of time, but thats about it. We can make
adjustments for true on demand clients like this so that even that
doesnt happen. we only do that so we know ahead of time which
ssa-names
are never used in outgoing edges, and never even have to check those.
Thats mostly an optimization for heavy users like EVRP. If you
want, I
can make that an option so there virtually no overhead
More importantly, the longer it remains alive, the more "reuse" of
ranges you will get.. If there is not a pattern of using variables
from earlier in the program it wouldnt really matter much.
In Theory, modifying the IL should be fine, it happens already in
places, but its not extensively tested under those conditions yet.
Note it's modifying the CFG as well.
bah, thats what I meant. as long as the IL is changed and CFG
updated to match, it should in theory work. And as long as existing
SSA_NAMEs dont have their meaning changes.. ie reusing an SSA_NAME
to have a different definition is likely to cause problems without
telling ranger that an SSA_NAME is now different.
There is an API somewhere which resets the global information that we
call for these scenarios. But that assumes we know when an name is
going to be reused or moved to a point where the global information
isn't necessary accurate anymore. It's not heavily used as these
cases are relatively rare.
The nastier case is when we release an SSA_NAME because it was dead
code, then later re-cycle it. If we're going to have Ranger instances
live across passes, then that becomes a much bigger concern.
we'd mostly need to add an API call when we de-register ssa-names and
add them back into the free list to the get_range_query() instance to
let it know an SSA_NAME is now dead. if no ranger is active, it just
wouldnt do anything. If ranger is alive, it would flush its global cache
of that ssa_name and move it back to not-processed.
I think thats all that would be required.. at least for that scenario.
My hope was to make it live across passes eventually... at least until
we do something major. For short gaps it would be beneficial, so that
if a threader runs right after a VRP pass, its fully populated already.
Andrew
