On 4/1/19 6:40 PM, Patrick Palka wrote:
> On Sun, Mar 3, 2019 at 5:16 PM Jeff Law 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 --
