https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-12-09
                 CC|                            |amacleod at redhat dot com
     Ever confirmed|0                           |1

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
I am working on this. 
The memory being allocated is the on-entry cache. With a very large CFG, the
on-entry cache propagator is consuming excessive memory.

First step is to recognize that if an ssa-name is never exported from GORI in
any block, then its only range is it's global range, and we don't need to
propagate any on-entry range around for it. I had planned to eventually get to
this, now its seems more important.  It is also a general speedup to avoid ever
looking at names which are irrelevant

This is true for all ranges except pointers which can become non-zero at a
dereference point.  And more generally, for anything which is the product of a
statement side effect. Dereferences are currently the only thing ranger tracks
which fall into this category. 

Implementing this tweak get back about half that memory.  The other half is
still tracking around the non-zero-ness of pointers across this massive CFG.

I have longer term plans for dealing with statement side effects like this that
are beyond the scope of this release, as well as different plans for pointer
ranges when we get to supporting other kinds of ranges beyond just integral.

If I then disable tracking pointer values via de-references in the on entry
cache, memory consumption goes back to normal.  Since hybrid EVRP still has
EVRP tracking the non-null pointer values , I am considering this as an option
just within EVRP for this release since we shouldn't miss anything.

I am continuing to look at it though and will come back with firmer conclusions

Reply via email to