mbox series

[0/4] tree-optimization/104288 - Add more granularity to non-null tracking

Message ID 4425f569-b42a-bd10-b3c7-bc110e9a5c95@redhat.com
Headers
Series tree-optimization/104288 - Add more granularity to non-null tracking |

Message

Andrew MacLeod Feb. 7, 2022, 2:29 p.m. UTC 
  I have a proposal for PR 104288.

This PR highlights the shortcomings of assuming that when the non-null 
property is seen within a block, that it applies to the entire block.

This is a 3 patch set, but is less dramatic than it sounds.  I just 
wanted to split it into small bits for safety and readability. The 
changes boil down to making the same queries as before, only with more 
precision.

patch set 1 changes the nonnull tracking system from a single bit to a 
pair of bits.  This uses the aligned_chunk code previously added to the 
sparse bitmaps, and the overall impact is minimal. This allows us to 
trace whether a block is non-null throughout the entire block, or just 
part of the block.

patch set 2 added a callback into ranger to register side effects of a 
statement after ranger_vrp has folded a statement during its domwalk.  
This simply checks if infer_nonnull_range is true on the statement just 
processed, and if it is, lets the non-null class know which then changes 
the state in that block to always non-null. There is no impact to the 
on-demand clients.

patch set 3 then added a new interface to non-null in which we can ask 
more refined question about the state of nonnull in a block.  All 
queries are then audited such that
   1) All queries within a block require that the nonnull property be 
100% guaranteed to be nonull in the block, or we dont adjust the range.
   2) Range on entry queries check if any dominator block has the 
non-null property at all.
This will ensure we don't make the assumption that non-null somewhere in 
the block always applies to the entire block.

The 3rd set also adds a more complicated test to the test suite to 
ensure we cannot remove a use early in the block even if we find it is 
non-null later in the same block, but then we will remove it later in 
the block.

the 4th patch is the GCC11 version.. much simpler, it only ever checks 
if non-null is true in a dominator, and doesn't check within the current 
block.  This works fine as EVRP runs in hybrid mode by default and evrp 
will pick up the inter-block granularity.

More details are provided with each patch. I think the risk is low since 
I do not believe we can do anything worse than we did before :-).  We 
can discuss alternatives if you think its too much at this stage.

ALL patches (in sequence) bootstrap on their own and each cause no 
regressions.

Andrew