On 4/1/19 6:40 PM, Patrick Palka wrote: > On Sun, Mar 3, 2019 at 5:16 PM Jeff Law <l...@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. >> >> >> >>> >>> * 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. >> >> >>> >>> * 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. > > Hi Jeff, > > I read your proposal from 2005 (I think the main part is > https://gcc.gnu.org/ml/gcc/2005-11/msg00040.html) and I wonder how > your position has changed since the uninit pass has been made > predicate-aware. I don't think it's changed that much, if at all. The predicate stuff has all the same issues that we have with other analysis/optimizations that intersect with this space.
By that I mean the predicate analysis code is still quite sensitive to the shape of the CFG -- seemingly unrelated changes earlier in the pipeline can easily change the shape of the CFG and confuse the predicate analysis code resulting in false positives. Even so I think there's a lot of interesting value in the predicate analysis bits, hence my desire to break it into an analysis engine and a client (uninit warnings). We can then re-use the analysis engine elsewhere. > > I see what you mean about breaking the predicate analysis out from the > rest of the uninit pass. Would that be a good start of a project on > improving the uninit pass? If so, I have in mind a project proposal > that would consist of: > > 1. breaking out the predicate analysis from the rest of the uninit pass, Right. I haven't dug deeply here, but at a high level marking an infeasible path detected by predicate analysis seems like what we're shooting for. The client then uses those markings to either suppress warnings or optimize the path. Other passes could conceivably mark infeasible paths as well. The threader for example does discover some infeasible paths, but leaves them in the IL if they're too expensive to remove. > 2. enhancing the uninit pass to detect uninitialized uses of memory > operands, e.g. PR 19430) (I think this could be doable by reusing > most of the existing pass that operates on SSA_NAMEs? I am not > exactly sure what the complications are), There's some bits for this already done by Richi and others. I think one of the things we want to do is distinguish between simple scalars vs aggregates/addressables for uninit warnings. I haven't dug into the problems we have with addressables/aggregates, but I suspect that aliasing likely gets in the way often of doing a good job. I don't want to creep the scope, but this class of problems interacts with DSE and SRA tightly. ISTM (and others) that there's commonality in the analysis necessary to do a good job for these problems. So it's probably worth digging into what we do in DSE and SRA and the aliasing code and see what can be re-used/enhanced. > 3. enhancing the predicate analysis to fix genuine bugs like PR 61112, WIthout digging in deeply, this looks like either a failure to thread jumps or a case where jump threading decided it was too costly to optimize. I'd start there before worrying much about the uninit bits for 61112. Also note that some of of Andrew/Aldy's work is putting in infrastructure to address other jump threading limitations exposed by various BZs. Many of the BZs related to false positive uninit warnings for scalars I have state on. I'm happy to pass that state along. > 4. adding noisiness levels (ideally non-numeric ones, as Eric > suggested) to -Wmaybe-uninitialized that controls > whether to warn about uses which the uninit pass gives up on. Yes. > > Would this be a reasonable project for GSoC? If so, would anyone be > willing to mentor it? Maybe -- we (Red Hat) have had problems in the past with GSoC results, but I think that you've already shown a stronger understanding of GCC internals with prior GSoC work. So I may be able to push mgt here to get some bandwith for you. > > I also posted a proposal template for the aforementioned > TREE_NO_WARNING project, and I wonder which project would be more > appropriate for GSoC if one had to choose. I think either probably works for GSoC -- as long as you can carve up milestones as I think either could potentially go beyond the scope typically covered by GSoC. > >> >>> >>> * 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 :-) > > Would such a general bug-fixing project be appropriate for GSoC? If > so, I can certainly submit a proposal, if anyone is willing to mentor > it. I think so, especially if there's a cluster of related bugs (like the uninit stuff we've touched on). Jeff
