This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=


On Mon, Jan 23, 2017 at 5:07 PM, Jeff Law <law@redhat.com> wrote:
> On 01/23/2017 02:50 AM, Richard Biener wrote:
>>>>
>>>>
>>>> So ideally DOM and EVRP would merge and CCP, copyprop and VRP
>>>> would merge.  It's probably not possible (or wise) to merge their
>>>> lattices
>>>> (maybe to some extent)
>>>
>>>
>>> DOM's equivalency tables could be easily superceded by other
>>> implementations.  It's just two datastructures.  A trivial const/copy
>>> table
>>> and a stack to allow unwinding the state of the const/copy table.
>>> Throwing
>>> away the basic const/copy table and replacing it with something built by
>>> copyprop ought to be trivial.
>>>
>>> The big thing that would be left would be the scoped hash table for
>>> tracking
>>> redundant expressions.  But I don't think that we'd necessarily have to
>>> rip
>>> that out to merge DOM with one of hte other passes.
>>>
>>> Hell we know DOM can fit well in any dominator based walk -- we used to
>>> do
>>> it as part of the into-ssa transformation.
>>
>>
>> Sure.
>>
>> The question is whether we want to make warning "passes" more expensive
>> by essentially doing a [E]VRP/DOM pass (but not doing any IL transform).
>>
>> I believe doing that is more reasonable than doing their own hacky
>> analysis.
>>
>> Having less passes to choose to copy from for such static analysis (and
>> the
>> ability to tame compile-time by some switches) would be a good thing to
>> have.
>
> Very true.  But your comment seemed to be about merging DOM and EVRP or
> other passes -- which is certainly possible and possibly even desirable.
>
> The more I look at our SCCVN implementation, the more I want to explore
> trying to re-use that infrastructure to simplify DOM.

Certainly having a single way to hash/record stmts/expressions on GIMPLE would
be nice.  Not sure if the SCCVN one is perfect (enhancing the memory
part further
is on my TODO list).

But I also want to merge SCCVN and DOM in the end.  Well, rip out the 'SCC'
part of SCCVN and replace it with a RPO style VN which makes it very similar
to DOM.  Ideally we'd have one "VN" we can configure (like enable a VRP lattice,
disable memory handling to get a pure CCP, disable optimistic VN and thus
require no iteration, etc.).

It may make sense to keep (a similarly single!) SSA-propagator based VN
(ccp/copyprop/VRP).

Richard.

>
> Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]