Re: GSoC Project Ideas

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

On Mon, Mar 4, 2019 at 12:16 AM Jeff Law <law@redhat.com> wrote:
>
> On 3/3/19 4:06 PM, Patrick Palka wrote:
> > Hi everyone,
> >
> > I am very interested in working on GCC as part of GSoC this year.  A few years
> > ago I was a somewhat active code contributor[1] and unfortunately my
> > contributing waned once I went back to school, but I'm excited to potentially
> > have the opportunity to work on GCC again this summer.  My contributions were
> > mainly to the C++ frontend and to the middle end, and I've been thinking about
> > potential projects in these areas of the compiler.  Here are some project ideas
> > related to parts of the compiler that I've worked on in the past:
> >
> >   * Extend VRP to track unions of intervals
> >     (inspired by comment #2 of PR72443 [2])
> >       Value ranges tracked by VRP currently are represented as an interval or
> >       its complement: [a,b] and ~[a,b].  A natural extension of this is
> >       to support unions of intervals, e.g. [a,b]U[c,d].  Such an extension
> >       would make VRP more powerful and at the same time would subsume
> >       anti-ranges, potentially making the code less complex overall.
> You should get in contact with Aldy and Andrew.  I believe their work
> already subsumes everything you've mentioned here.

I'm not so sure so work on this would definitely be appreciated.

> >
> >   * Make TREE_NO_WARNING more fine-grained
> >     (inspired by comment #7 of PR74762 [3])
> >       TREE_NO_WARNING is currently used as a catch-all marker that inhibits all
> >       warnings related to the marked expression.  The problem with this is that
> >       if some warning routine sets the flag for its own purpose,
> >       then that later may inhibit another unrelated warning from firing, see for
> >       example PR74762.  Implementing a more fine-grained mechanism for
> >       inhibiting particular warnings would eliminate such issues.
> Might be interesting.  You'd probably need to discuss the details further.

I guess an implementation could use TREE_NO_WARNING (or gimple_no_warning_p)
as indicator that there's out-of-bad detail information which could be stored as
a map keyed off either a location or a tree or gimple *.

> >
> >   * Make -Wmaybe-uninitialized more robust
> >       (Inspired by the recent thread to move -Wmaybe-uninitialized to
> > -Wextra [4])
> >       Right now the pass generates too many false-positives, and hopefully that
> >       can be fixed somewhat.
> >       I think a distinction could be made between the following two scenarios in
> >       which a false-positive warning is emitted:
> >         1. the pass incorrectly proves that there exists an execution path that
> >            results in VAR being used uninitialized due to a deficiency in the
> >            implementation, or
> >         2. the pass gives up on exhaustively verifying that all execution paths
> >            use VAR initialized (e.g. because there are too many paths to check).
> >            The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently control
> >            when this happens.
> >       I'd guess that a significant fraction of false-positives occur due to the
> >       second case, so maybe it would be worthwhile to allow the user to suppress
> >       warnings of this second type by specifying a warning level argument, e.g.
> >       -Wmaybe-uninitialized=1|2.
> >       Still, false-positives are generated in the first case too, see e.g.
> >       PR61112.  These can be fixed by improving the pass to understand such
> >       control flow.
> I'd suggest you look at my proposal from 2005 if you want to improve
> some of this stuff.
>
> You might also look at the proposal to distinguish between simple
> scalars that are SSA_NAMEs and the addressable/aggregate cases.
>
> In general I'm not a fan of extending the predicate analysis as-is in
> tree-ssa-uninit.c.  I'd first like to see it broken into an independent
> analysis module.  The analysis it does has applications for other
> warnings and optimizations.  Uninit warnings would just be a client of
> hte generic analysis pass.
>
> I'd love a way to annotate paths (or subpaths, or ssa-names) for cases
> where the threaders identify a jump threading path, but don't actually
> optimize it (often because it's a cold path or to avoid code bloat
> problems).   THese unexecutable paths that we leave in the CFG are often
> a source of false positives when folks use -O1, -Os and profile directed
> optimizations.  Bodik has some thoughts in this space, but I haven't
> really looked to see how feasible they are in the real world.
>
> >
> >   * Bug fixing in the C++ frontend / general C++ frontend improvements
> >       There are 100s of open PRs about the C++ frontend, and the goal here
> >       would just be to resolve as many as one can over the summer.
> Bugfixing is always good :-)
>
> jeff