[PATCH] Improvements to fur_source interface class, enhanced stmt folding options.

Andrew MacLeod amacleod@redhat.com
Wed Jun 9 01:14:02 GMT 2021

I recently introduced the fur_source class as an intermediary between 
the Fold_Using_Ranges (FUR) class and where to pick up any ssa_names 
that it needs.    The initial idea was to abstract out a set of 
frequently changing parameters so the client fold routines wouldn't have 
to change every time we added a new way to do something with a 
statement.  Its also used by gori_compute when unwinding to allow for 
access to non-range-ops stmts when processing.

That said, I hadn't really formalized it, so fold_using_ranges was 
accessing its members frequently.  We have encountered an opportunity to 
add something else which is useful,. but where the internals should be 

This patch a) formalizes the API (hiding the internals)  b) virtualizes 
the functions so we can use inheritance and not use conditions, and  c) 
adds the ability to pick up operands from a vector or list of ranges.

There is no real visual difference to consumers since its an interface 
layer they don't normally see.  The net effect is now there are multiple 
versions of fold_stmt that all behave quite nicely:

bool fold_range (irange &r, gimple *s, range_query *q = NULL);
bool fold_range (irange &r, gimple *s, edge on_edge, range_query *q = NULL);
bool fold_range (irange &r, gimple *s, irange &r1);
bool fold_range (irange &r, gimple *s, irange &r1, irange &r2);
bool fold_range (irange &r, gimple *s, unsigned num_elements, irange 

Now we can calculate ranges for a stmt,, ask for its range to be 
calculated as if it were on an edge, or we can supply one or more ranges 
to it to have the fold performed.  This latter set is akin to the old 
gimple_range_fold() routine we had, expect it only worked on a range-ops 
stmt, whereas this will work on any kind of stmt, including a PHI node.

The routines have all been enhanced so that if a range_query is not 
provided, it will invoke the default range_query.   It will also invoke 
the default query if a list of ranges is supplied and it requires 
additional ranges to resolve the stmt being queried.

There will probably be some additional tweaks going forward, especially 
since the list routines haven't really been tested. Aldy will be using 
them shortly, so that will be the test bed :-)

Performance is basically a wash since there is a slight overhead for the 
virtual function calls, but it is offset by no longer have to do any 
conditional checks in the get_operand() routine.

Bootstraps on x86_64-pc-linux-gnu with no regressions.  Pushed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fur.patch
Type: text/x-patch
Size: 16885 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210608/933173d2/attachment.bin>

More information about the Gcc-patches mailing list