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
