PING^2: Fwd: SSA range class and removal of VR_ANTI_RANGEs

[Richard Biener]

On Mon, Jul 17, 2017 at 8:51 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> PING PING
>
> Hi folks.
>
> The following is another iteration of the SSA range class, taking into
> account many of the suggestions posted on this thread, especially the
> addition of a memory efficient class for storage, folding non-zero
> bits back into the range information, C++ suggestions by Martin, and
> some minor suggestions.
>
> Most importantly, I have included an irange_storage class that uses
> trailing_wide_ints<5>.  This produces far better results that my
> previous incarnation with wide_int[6] :).
>
> The storage class is basically this:
>
> class GTY((variable_size)) irange_storage
> {
>   friend class irange;
>  public:
>     /* Maximum number of pairs of ranges allowed.  */
>   static const unsigned int max_pairs = 2;
>   /* These are the pair of subranges for the irange.  The last
>      wide_int allocated is a mask representing which bits in an
>      integer are known to be non-zero.  */
>   trailing_wide_ints<irange::max_pairs * 2 + 1> trailing_bounds;
> }
>
> Compare this with mainline which has trailing_wide_ints<3>.  The extra
> 2 items in this patchset chew up two 64-bit words, for an additional
> 16 bytes per range in SSA_NAME_RANGE_INFO.  No additional storage is
> needed for SSA_NAMEs per se.
>
> I looked at Jakub's suggestion of compiling insn-recog.c.  Although I
> don't see 4M SSA_NAMES nodes created Jakub sees, I do see a little
> over a million when building with:
>
> ./cc1plus insn-recog.ii -fno-PIE -O2 -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables  -quiet -fsanitize=address,undefined
> -fmem-report
>
> I explored 3 different ways of measuring memory consumption:
>
> 1. /usr/bin/time -f "%M" ...., which measures maximum RSS usage.  This
> produced results within the noise.  The RSS usage differed slightly
> between runs, with no consistent difference between mainline and
> patch.
>
> 2. valgrind --tool=massif ...., no difference.  Perhaps the overhead
> of our GC hides any difference?
>
> 3. --enable-gather-detailed-mem-stats and -fmem-report ...
>
>         Total Allocated before: 2351658176
>         Total Allocated  after: 2353199328
>         diff: 1541152 (0.06%)
>
>         SSA_NAME nodes allocated: 1026694
>
> AFAICT with -fmem-report, a 2.35gig compilation consumes 1.5 more
> megs? This is total usage, and some of this gets cleaned up during GC,
> so the total impact is probably less.  Unless there is another
> preferred way of measuring memory usage, I think memory is a non-issue
> with this approach.
>
> Note, this is even before my pending patch avoiding generation of
> useless range information
> (https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01068.html).
>
> How does this look?

It's a change that on its own doesn't look worthwhile to me.

So please post the changes that will build ontop of this.  Like removing
anti-ranges from VRP or your on-demand value-range stuff.

Thanks,
Richard.

>
> Aldy