On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote: > > Would you need to LTO stream & merge the bitmaps / maps somehow? > > Yes. And if we do not throw unneeded warnings from the sets normally, LTO > streaming might be a good time to do that, so that we merge in only warnings > that will be tested during/post IPA. > > > (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. > > Right now we use it both for the case we've already emitted some diagnostics > and don't want to emit it again later, or for the case where we insert > something in the IL that a warning could be diagnosed on but we know we > don't want that. The latter is the case e.g. for when we add > TREE_NO_WARNING on the last value in a statement expression so that we don't > diagnose it as unused, or the case we are discussing here. > If we need queued diagnostics, sure, we could add it in, but I don't see a > need for that right now. vecs compared to bitmap might be larger and harder > to avoid duplicates. I guess we'd need to do some analysis though, and e.g. > if 99% of cases we need to disable just one warning and not multiple, > perhaps optimize for that case.
I was thinking we may want to use the same facility to record warnings we want to not emit if we later figure a stmt was in an unreachable region. For this we need to record the actual warning, not only the warning kind. Richard. > > Jakub
