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


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?

Aldy

Attachment: curr
Description: Text document


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