Re: [PATCH][4/n] Remove GENERIC stmt combining from SCCVN

[Jeff Law <law at redhat dot com>]

On 06/26/2015 03:24 AM, Richard Biener wrote:
> On Thu, 25 Jun 2015, Richard Biener wrote:
>
> > This moves fold_sign_changed_comparison.  Shows up in gcc.dg/pr55833.c
> >
> > I'll eventually massage it according to Jakubs suggestion to do a
> >
> > #ifndef HAVE_canonicalize_funcptr_for_compare
> > #define HAVE_canonicalize_funcptr_for_compare 0
> > #endif
> >
> > somewhere (defaults.h should work I guess).
> >
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> This runs into
>
> Running target unix//-m32
> FAIL: g++.dg/tree-ssa/calloc.C  -std=gnu++11  scan-tree-dump-not optimized
> "malloc"
>
> where we now optimize
>
>     n_5 = (size_t) n_4(D);
> ...
>     <bb 5>:
>     -  if (n_5 != 0)
>     +  if (n_4(D) != 0)
>
> but both VRP and DOM fail to record equivalences for n_5 from
> the updated condition (I have a patch to fix VRP but not DOM).
So you want an equivalence recorded for n_5, even though it no longer 
appears in the conditional (but presumably has other uses)?

DOM has some code for this already, but it's kind-of backwards from what 
you're trying to do in terms of when it's used.  That code might be 
factorable and usable elsewhere in DOM.




> I think we're simply missing a pass that can "properly" deal
> with this kind of stuff.  For example DOM could re-visit
> stmts which have uses of SSA names we added temporary
> equivalences for (ones that dominate the current block,
> others we'll (re-)visit anyway).  That would fix this testcase
> but to catch secondary effects you'd need to re-visit uses of
> the defs of the revisited stmts as well (if anything interesting
> was produced, of course).
This problem feels a bit like it's better handled by an optimizer 
independent of DOM.  Probably a backwards IL walking context sensitive 
optimizer.  I want to do something like that for threading, but haven't 
much pondered other use cases for that kind of structure.

If you could create a BZ and include the patches you're playing with and 
a reference to the failing test (calloc.C for -m32), it'd be appreciated.

Jeff