Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jul 29, 2019 at 6:03 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Jul 24, 2019 at 12:07:36PM -0600, Martin Sebor wrote:
> > > > There are a number of existing instances of setting TREE_NO_WARNING
> > > > to suppress -Wuninitialized, and some are the cause of known problems.
> > > > Bugs 51545, 58950, 74762, 74765 or 89697 are examples.  They all boil
> > > > down to the fact that there's just one bit for all warnings.  Jakub
> > > > mentioned adding a hash-map for this.  That seems like a simple and
> > > > good solution.
> > > I'm not sure how that really helps here.  We marking the MEM on the LHS
> > > and that's not a shared object.  I don't see how it's going to be
> > > significantly different using a hash map vs the bit in this circumstance.
> >
> > I don't know what Jakub had in mind but the mapping I envision is
> > one like hash_map<tree, bitmap> that would make it possible to set
> > a bit for each distinct warning for every tree node.  It would let
> > us set a bit for -Wuninitialized while leaving the bit for
> > -Warray-bounds (and all other warnings) clear.
>
> I had in mind something like a hash_map<tree, const_bitmap> / hash_map<gimple *,
> const_bitmap> (or just make it a <void *, const_bitmap>) where possibly the
> bitmaps would be shared, so have a hash table in which one would look up existing
> bitmaps containing particular sets of warnings and if not create a new one (and
> where the bitmaps would be const after creation).
> The TREE_NO_WARNING or gimple_no_warning bits would be a flag that one
> should look up the hash_map if needed, those bits clear would imply empty
> bitmap.  Routines that copy trees or gimple stmts, like copy_node or
> gimple_copy would take care of adding the new tree/gimple * into the
> hash_map if needed too.
> And, because we have a lot of warnings that are only emitted in the FEs, or
> say before IPA and not afterwards, we could also have spots where we'd
> replace the bitmaps with ones that don't have any of the no longer
> interesting warning bits.
> Say during gimplification we could drop TREE_NO_WARNING bit or not set
> gimple_no_warning if the bitmap only contains FE warning bits, or (perhaps
> more questionable whether worth it) replace with a const_bitmap that doesn't
> have those).

Would you need to LTO stream & merge the bitmaps / maps somehow?
(maybe "unmap" to sth else when streaming individual stmts)  Not sure if
a bitmap is really necessary, we could simply have a tree/gimple * -> vec<>
mapping with records about emitted (or queued) diagnostics, like
OPT_, message pairs or so.

Richard.

>
>         Jakub