On Fri, Dec 16, 2016 at 09:41:33AM -0500, Aldy Hernandez wrote:
> Hi folks.
>
> This is a follow-up on Jeff and Richi's interaction on the aforementioned PR
> here:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01397.html
>
> I decided to explore the idea of analyzing may-undefness on-demand, which
> actually looks rather cheap.
>
> BTW, I don't understand why we don't have auto_bitmap's, as we already have
> auto_sbitmap's. I've implemented the former based on auto_sbitmap's code we
> already have.
No good reason, it just hasn't been done yet.
I'm tempted to fit both this and auto_sbitmap into a unique_ptr with
custom deletor, but that would make it hard to do small object
optimizations, so maybe it isn't actually a great idea.
> +class auto_bitmap
> +{
> + public:
> + auto_bitmap () { bits = BITMAP_ALLOC (NULL); }
> + ~auto_bitmap () { BITMAP_FREE (bits); }
We could make the member a bitmap_head, and then use bitmap_initialize
and bitmap_clear in the ctor and dtor, that'd save a alloc / dealloc.
You might also want to use the CXX_MEM_STAT macros on the ctor to get
better attribution of memory usage.
> + // Prevent making a copy that references our bitmap.
> + auto_bitmap (const auto_bitmap &);
> + auto_bitmap &operator = (const auto_bitmap &);
> +#if __cplusplus >= 201103L
> + auto_bitmap (auto_bitmap &&);
> + auto_bitmap &operator = (auto_bitmap &&);
We could actually support moving bitmaps pretty easily, though we would
need to do the auto_ptr style hacks to keep building as c++98. I'll
probably do that work eventually for unique_ptr, but its kind of late
for gcc 8 unless we just use it to fix memory leaks.
> +#endif
> +
> + bitmap bits;
style guide would say that should be m_bits I believe.
Trev
sorry about the lag here.
