On Mon, Jul 17, 2017 at 8:51 AM, Aldy Hernandez <al...@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
