Re: SSA range class and removal of VR_ANTI_RANGEs

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, May 31, 2017 at 05:36:12PM +0200, Richard Biener wrote:
> On May 31, 2017 5:10:04 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
> >On Wed, May 31, 2017 at 10:20:51AM -0400, Aldy Hernandez wrote:
> >> The biggest number of SSA_NAMEs I saw was actually 472,225.  Of
> >these,
> >> 357,032 were non-pointers, so could conceivably have range
> >information. In
> >> reality, 77,398 had range information, so 16% of all pointer and
> >non-pointer
> >> SSA_NAMEs actually have range information.
> >
> >I've tried to look just at insn-recog.c with the usual stage3 flags +
> >-fsanitize=address,undefined and I see there
> >ssa_name_nodes_created
> >4092344
> >(of course, that doesn't mean there are 4M SSA_NAMEs all live at the
> >same
> >time, but I think they don't go through ggc_free and thus the only way
> >that
> >number goes down is during GC.  There are both 72 and 80 bytes alloc
> >pools,
> >even a 32MB increase is something we shouldn't ignore.
> >Furthermore, as e.g. PR80917 shows, we really should track nonzero bits
> >next
> >to value ranges, the current tracking of it only in tree-ssa-ccp which
> >doesn't have ASSERT_EXPRs nor any kind of framework to do something
> >similar
> >without them is insufficient.
> 
> I think the important part to recognize is that the VR type used during
> propagation does (and likely should) not have to be the same as that used
> for long-term storage alongside SSA names.
> 
> The first thing to do is improve the one we use internally in VRP where we
> can also add a separate bit-lattice easily (though we have to iterate
> until both converge).

I believe Andrew/Aldy's goal is to make the "during VRP propagation" vs.
in other passes line fuzzier, but I agree it would be best to do it
like wide_int can - have a template that can work on different range/nz bits
storages, and have a compact storage for the on SSA_NAME data and
less compact one for other purposes.

	Jakub