From: Richard Biener <richard.guenther@gmail.com>
To: Jeff Law <law@redhat.com>
Cc: Patrick Palka <ppalka007@gmail.com>, GCC Development <gcc@gcc.gnu.org>
Subject: Re: GSoC Project Ideas
Date: Mon, 04 Mar 2019 12:13:00 -0000 [thread overview]
Message-ID: <CAFiYyc0LwhUgmggu8bAmE614x_i2DC0bCfOD4f49TjarwVUxMw@mail.gmail.com> (raw)
In-Reply-To: <cdc582a7-2922-7673-d556-379c6f3083b8@redhat.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
next prev parent reply other threads:[~2019-03-04 12:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-03 23:06 Patrick Palka
2019-03-03 23:16 ` Jeff Law
2019-03-04 12:13 ` Richard Biener [this message]
2019-03-04 12:23 ` Jakub Jelinek
2019-03-04 13:17 ` Richard Biener
2019-03-07 18:20 ` Martin Sebor
2019-03-08 10:35 ` Richard Biener
2019-04-01 23:43 ` Patrick Palka
2019-04-03 12:08 ` Richard Biener
2019-04-17 14:57 ` Joseph Myers
2019-04-17 18:33 ` Martin Sebor
2019-04-02 0:41 ` Patrick Palka
2019-04-09 15:42 ` Jeff Law
2019-03-04 10:57 ` P J P
2019-03-05 15:43 ` Eric Gallager
-- strict thread matches above, loose matches on Subject: below --
2014-02-17 2:49 GSoC project ideas Maxim Kuvyrkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFiYyc0LwhUgmggu8bAmE614x_i2DC0bCfOD4f49TjarwVUxMw@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=law@redhat.com \
--cc=ppalka007@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).