SSA range class and removal of VR_ANTI_RANGEs
Richard Biener
richard.guenther@gmail.com
Wed May 31 15:38:00 GMT 2017
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).
Richard.
> Jakub
More information about the Gcc-patches
mailing list