On 12/16/2016 12:29 AM, Trevor Saunders wrote:
On Thu, Dec 15, 2016 at 06:54:43PM -0700, Jeff Law wrote:
unsigned cnt = 0;
+ bitmap live_bytes = NULL;
+ bitmap orig_live_bytes = NULL;
*use_stmt = NULL;
+ /* REF is a memory write. Go ahead and get its base, size, extent
+ information and encode the bytes written into LIVE_BYTES. We can
+ handle any case where we have a known base and maximum size.
+
+ However, experimentation has shown that bit level tracking is not
+ useful in practice, so we only track at the byte level.
+
+ Furthermore, experimentation has shown that 99% of the cases
+ that require byte tracking are 64 bytes or less. */
+ if (valid_ao_ref_for_dse (ref)
+ && (ref->max_size / BITS_PER_UNIT
+ <= PARAM_VALUE (PARAM_DSE_MAX_OBJECT_SIZE)))
+ {
+ live_bytes = BITMAP_ALLOC (NULL);
+ orig_live_bytes = BITMAP_ALLOC (NULL);
+ bitmap_set_range (live_bytes,
+ ref->offset / BITS_PER_UNIT,
+ ref->max_size / BITS_PER_UNIT);
+ bitmap_copy (orig_live_bytes, live_bytes);
would it maybe make sense to use sbitmaps since the length is known to
be short, and doesn't change after allocation?
So a few interesting things have to be dealt if we want to make this
change. I already mentioned the need to bias based on ref->offset so
that the range of bytes we're tracking is represented 0..size.
While we know the length of the potential dead store we don't know the
length of the subsequent stores that we're hoping make the original a
dead store. Thus when we start clearing LIVE_BYTES based on those
subsequent stores, we have to normalize those against the ref->offset of
the original store.
What's even more fun is sizing. Those subsequent stores may be
considerably larger. Which means that a bitmap_clear_range call has to
be a hell of a lot more careful when working with sbitmaps (we just
happily stop all over memory in that case) whereas a bitmap the right
things will "just happen".
On a positive size since we've normalized the potential dead store's
byte range to 0..size, it means computing trims is easier because we
inherently know how many bits were originally set. So compute_trims
becomes trivial and we can simplify trim_complex_store a bit as well.
And, of course, we don't have a bitmap_{clear,set}_range or a
bitmap_count_bits implementation for sbitmaps.
It's all a bit of "ugh", but should be manageable.
Jeff
