From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-480087-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 87646 invoked by alias); 11 Mar 2015 16:12:19 -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 87328 invoked by uid 48); 11 Mar 2015 16:12:15 -0000
From: "acsawdey at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65391] New: unnecessary load of conditionally updated pointer in loop
Date: Wed, 11 Mar 2015 16:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: acsawdey at linux dot vnet.ibm.com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-65391-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: 2015-03/txt/msg01231.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391

            Bug ID: 65391
           Summary: unnecessary load of conditionally updated pointer in
                    loop
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acsawdey at linux dot vnet.ibm.com
                CC: dje at gcc dot gnu.org, pthaugen at us dot ibm.com

When compiling for powerpc64 or powerpc64le with -O3, a load and store of
*o_ptr is done inside the loop. 

If you remove the if statement and make the update unconditional, then the load
goes away and the store is deferred until after the loop.

If you remove the __restrict__ keywords, then the store remains in the loop in
either case as expected. However the load is still done in the loop if the
update is conditional.

void compute_object_gain(long * __restrict__ p_ptr, long * __restrict__ o_ptr,
long g_order)
{
    long a_binding;
    *o_ptr = 0;
    while(*p_ptr!=0) {
       a_binding = *p_ptr;
       if(a_binding <= g_order)
          *o_ptr += a_binding;
        p_ptr++;
    }
}

This behavior is consistent on 4.1, 4.5, 4.6, 4.7, 4.8, and 5.0 (trunk 220806).