On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote: > On Tue, Oct 4, 2022 at 9:55 AM Richard Biener > wrote: > > > > > > Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches < > gcc-patches@gcc.gnu.org>: > > > > > > The reason the nonzero mask was kept in a tree was basically inertia, > > > as everything in irange is a tree. However, there's no need to keep > > > it in a tree, as the conversions to and from wide ints are very > > > annoying. That, plus special casing NULL masks to be -1 is prone > > > to error. > > > > > > I have not only rewritten all the uses to assume a wide int, but > > > have corrected a few places where we weren't propagating the masks, or > > > rather pessimizing them to -1. This will become more important in > > > upcoming patches where we make better use of the masks. > > > > > > Performance testing shows a trivial improvement in VRP, as things like > > > irange::contains_p() are tied to a tree. Ughh, can't wait for trees in > > > iranges to go away. > > > > You want trailing wide int storage though. A wide_int is quite large. > > Absolutely, this is only for short term storage. Any time we need > long term storage, say global ranges in SSA_NAME_RANGE_INFO, we go > through vrange_storage which will stream things in a more memory > efficient manner. For irange, vrange_storage will stream all the > sub-ranges, including the nonzero bitmask which is the first entry in > such storage, as trailing_wide_ints. > > See irange_storage_slot to see how it lives in GC memory. > That being said, the ranger's internal cache uses iranges, albeit with a squished down number of subranges (the minimum amount to represent the range). So each cache entry will now be bigger by the difference between one tree and one wide int. I wonder if we should change the cache to use vrange_storage. If not now, then when we convert all the subranges to wide ints. Of course, the memory pressure of the cache is not nearly as problematic as SSA_NAME_RANGE_INFO. The cache only stores names it cares about. Aldy