This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SSA range class and removal of VR_ANTI_RANGEs


On May 31, 2017 6:28:26 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>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

I realize that.  But for caching purposes they do have to keep a sparse lattice anyway which can use a more precise info (and also expose that through another API than the persistent one).
It's hopefully going to be much like SCEV.

I've not yet seen any code of course (not that I have high hopes...)

Richard.


, 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]