On Tue, Nov 26, 2013 at 9:43 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Nov 25, 2013 at 09:52:47PM +0000, Richard Sandiford wrote: >> But my point is that at the moment we always have trees for the ranges >> we want to record, so it seems simplest just to store those in the >> structure. I was thinking of something like the attached (only just >> started testing, no changelog yet). > > You have the tree at VRP time, that doesn't necessarily mean the tree is > directly in the IL somewhere (with the right type). So, if you have very > large function, you can have tons of constants there that aren't cached > nor anywhere in the IL directly, so ggc_collect could normally throw them > away, but if they are referenced from the SSA_NAME_RANGE_INFO, they can't > be.
Btw, for the cases where I objected to using widest_int in structs that reside on the heap (or in GC memory) you can just keep the old code using double_int, no? Thus, leave the problem that 1) this is a host dependence, 2) it blocks double-int from being removed, for fix/cleanup after the merge? That said, I'd prefer to keep range_info_def as-is (using double_int) for the wide-int merge. Likewise for the nb_iteration stuff in cfgloop.h. Thanks, Richard. > > Jakub
