On May 31, 2017 5:10:04 PM GMT+02:00, Jakub Jelinek <ja...@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). Richard. > Jakub
