From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-450791-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6738 invoked by alias); 7 May 2014 11:50:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 6667 invoked by uid 48); 7 May 2014 11:50:05 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61034] Optimizing takes too many passes
Date: Wed, 07 May 2014 11:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61034-4-9bh31pb3RV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61034-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61034-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00483.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> (In reply to Marc Glisse from comment #7)
> > (In reply to rguenther@suse.de from comment #6)
> > > that's a conditional assignment AFAICS
> > 
> > Ah, you are right of course. It shouldn't be conditional, but it will take a
> > VRP pass to notice that. If I schedule another FRE right after VRP1, things
> > optimize nicely, and after some cleanup by DOM+DSE, DCE2 can remove all
> > malloc+free. However, if I don't add this extra FRE pass, we somehow don't
> > manage. Note that in the PRE dump, with just your patch (no extra pass), I
> > see:
> > 
> >   pretmp_92 = 1;
> >   _235 = pretmp_92;
> >   if (_235 == 0)
> > 
> > and these conditions seem to be what prevents us from finishing the job.
> 
> Yeah.  Looks somewhat tricky, but I'll play with it.  Meanwhile testing
> a proper patch for the first issue.

Ok, so we have after PRE

<bb 39>:
_240 = 2;
_241 = 1;
MEM[(struct O *)_73].count = _241;
if (1 == 0)
  goto <bb 40>;
else
  goto <bb 53>;

<bb 53>:
goto <bb 41>;

<bb 40>:
__builtin_free (_73);
pretmp_48 = MEM[(struct O *)_73].count;

<bb 41>:
# prephitmp_35 = PHI <1(53), pretmp_48(40)>
D.2328 ={v} {CLOBBER};
D.2328 ={v} {CLOBBER};
_242 = prephitmp_35;
if (_242 == 1)
  goto <bb 42>;
else
  goto <bb 54>;

and only CFG-cleanup will simplify the PHI node by removing the unreachable
path and thus we end up with

_242 = 1;
if (_242 == 1)

of course the above shows another case where free() bogusly is thought
to clobber the load from count.  But in general as SCCVN/PRE is not
predicate aware (or optimistically treating edges as not executed) the
issue cannot always be avoided.  Applying copy-propagation during
elimination would make CFG-cleanup do the job though.