From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10998 invoked by alias); 20 Oct 2014 07:35:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10980 invoked by uid 48); 20 Oct 2014 07:35:46 -0000 From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/63599] "wrong" branch optimization with Ofast in a loop Date: Mon, 20 Oct 2014 07:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg01500.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63599 --- Comment #1 from Andrew Pinski --- The tree level looks like this: t_13 =3D VEC_COND_EXPR ; ret_14 =3D VEC_COND_EXPR { 4.142135679721832275390625e-1, 4.142135679721832275390625e-1, 4.142135679721832275390625e-1, 4.142135679721832275390625e-1 }, { 7.85398185253143310546875e-1, 7.85398185253143310546875e-1, 7.85398185253143310546875e-1, 7.85398185253143310546875e-1 }, { 0.0, 0.0, 0.0, 0.0 }>; t_16 =3D _9 !=3D 0 ? t_13 : t_4; ret_15 =3D _9 !=3D 0 ? ret_14 : { 0.0, 0.0, 0.0, 0.0 }; >"movmskps %xmm8, %edx" > does not protect the code in the if block... Yes it does just not the way you think it does. Notice the last two statements are conditional expressions. And that gets translated into the following: testl %edx, %edx jne .L9 movaps %xmm3, %xmm1 pxor %xmm2, %xmm2 .L9: So if anything it is a missed optimization dealing with conditional moves w= ith vectors without a vector comparison. >>From gcc-bugs-return-464480-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 20 07:39:48 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 21144 invoked by alias); 20 Oct 2014 07:39:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 20850 invoked by uid 55); 20 Oct 2014 07:39:44 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory Date: Mon, 20 Oct 2014 07:44: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.8.0 X-Bugzilla-Keywords: memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-10/txt/msg01501.txt.bz2 Content-length: 638 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #6 from rguenther at suse dot de --- On Sun, 19 Oct 2014, evgeniya.maenkova at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 > > --- Comment #5 from Evgeniya Maenkova --- > Also, I collect massif data and see no tree-ssa-lim in it (i mean in top > contributors). > > So what do you think? > > (How did you measured 1,8Gb caused by lim? - this is for me to understand > whether this bug is actual or not) I basically watched 'top' with breakpoints at the start and end of LIM.