On Tue, Feb 8, 2022 at 2:33 AM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On 2/7/22 09:29, Andrew MacLeod wrote:
> > I have a proposal for PR 104288.
> >
> > ALL patches (in sequence) bootstrap on their own and each cause no
> > regressions.
>
> I've been continuing to work with this towards the GCC13 solution for
> statement side effects.  And There is another possibility we could
> pursue which is less intrusive
>
> I adapted the portions of patch 2/4 which process nonnull, but changes
> it from being in the nonnull class to being in the cache.
>
> THe main difference is it continues to use a single bit, just changing
> all uses of it to *always* mean its non-null on exit to the block.
>
> Range-on-entry is changed to only check dominator blocks, and
> range_of_expr doesn't check the bit at all.. in both ranger and the cache.
>
> When we are doing the block walk and process side effects, the on-entry
> *cache* range for the block is adjusted to be non-null instead.   The
> statements which precede this stmt have already been processed, and all
> remaining statements in this block will now pick up this new non-value
> from the on-entry cache.  This should be perfectly safe.
>
> The final tweak is when range_of_expr is looking the def block, it
> normally does not have an on entry cache value.  (the def is in the
> block, so there is no entry cache value).  It now checks to see if we
> have set one, which can only happen when we have been doing the
> statement walk and set the on-entry cache with  a non-null value.  This
> allows us to pick up the non-null range in the def block too... (once we
> have passed a statement which set nonnull of course).
>
> THis patch provides much less change to trunk, and is probably a better
> approach as its closer to what is going to happen in GCC13.
>
> Im still working with it, so the patch isnt fully refined yet... but it
> bootstraps and passes all test with no regressions.  And passes the new
> tests too.   I figured I would mention this before you look to hard at
> the other patchset.    the GCC11 patch doesn't change.
>
> Let me know if you prefer this.... I think I do :-)  less churn, and
> closer to end state.

Yes, I very much prefer this - some comments to the other patches
still apply to this one.  Like using get_nonnull_args and probably
adding a bail-out to computing ranges from stmts that can throw
internally or have abnormal control flow (to not get into range-on-exit
vs. normal vs. exceptional or abnormal edges).

Richard.

>
> Andrew
>
>
>
>
>

Reply via email to