On Tue, 2019-12-03 at 18:17 +0100, Jakub Jelinek wrote:
> On Tue, Dec 03, 2019 at 11:52:13AM -0500, David Malcolm wrote:
> > > > Our plugin "interface" as such is very broad.
> > >
> > > Just to sneak in here I don't like exposing our current plugin
> > > "non-
> > > API"
> > > more. In fact I'd just build the analyzer into GCC with maybe an
> > > option to disable its build (in case it is very fat?).
> >
> > My aim here is to provide a way for distributors to be able to
> > disable
> > its build - indeed, for now, for it to be disabled by default,
> > requiring opting-in.
> >
> > My reasoning here is that the analyzer is middle-end code, but
> > isn't as
> > mature as the rest of the middle-end (but I'm working on getting it
> > more mature).
> >
> > I want some way to label the code as a "technology preview", that
> > people may want to experiment with, but to set expectations that
> > this
> > is a lot of new code and there will be bugs - but to make it
> > available
> > to make it easier for adventurous users to try it out.
> >
> > I hope that makes sense.
> >
> > I went down the "in-tree plugin" path by seeing the analogy with
> > frontends, but yes, it would probably be simpler to just build it
> > into
> > GCC, guarded with a configure-time variable. It's many thousand
> > lines
> > of non-trivial C++ code, and associated selftests and DejaGnu
> > tests.
>
> I think it is enough to document it as tech preview in the
> documentation,
> no need to have it as an in-tree plugin. We have lots of options
> that had
> such a state (perhaps undeclared) over the years, I'd consider
> -fvtable-verify= to be such an option, or in the past e.g.
> -fipa-matrix-reorg or -fipa-struct-reorg. And 2.5% code growth isn't
> that
> bad. So, as long as the option isn't enabled by default, I think
> we'd be
> fine.
FWIW I did some testing of v4 of the patch kit [1], which drops the in-
tree plugin idea in favor of simply building the analyzer into the
compiler as a regular IPA pass. The pass is disabled by default
(enabled by -fanalyzer). There is also a configure-time option to
disable building it (it's built by default).
I did 3 bootstraps of a release build of x86_64-pc-linux-gnu:
- unpatched,
- with the kit but with --disable-analyzer, and
- with the kit, with the analyzer enabled.
Here are the sizes of cc1 and cc1plus in bytes in each build, after
stripping debuginfo (and showing the change relative to the unpatched
build:
Unpatched: With kit:
Disabled change: Enabled change:
cc1 25778720 25815672 +36952 (+0.1%) 26270328 +491608 (+1.9%)
cc1plus 27355296 27388152 +32856 (+0.1%) 27842808 +487512 (+1.8%)
So it's a little less than 2% code growth.
Dave
[1] see https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer for the
various links
