On Sat, Dec 17, 2016 at 01:19:41AM -0700, Jeff Law wrote:
> 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.
yeah, but that seems like enough work that you could reasonably stick
with bitmap instead.
Trev
p.s. sorry I've been falling behind lately.
>
> Jeff
