From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99128 invoked by alias); 24 Jun 2015 07:34:20 -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 99020 invoked by uid 48); 24 Jun 2015 07:34:15 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/66646] small loop turned into memmove because of tree ldist Date: Wed, 24 Jun 2015 07:34: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: 6.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: keywords bug_status cf_reconfirmed_on cc everconfirmed 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: 2015-06/txt/msg02373.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66646 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed| |2015-06-24 CC| |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Well, even if it is a small loop the theory is that mem* inline expansion will produce better code than the loop copying chars. niter is : if (flag_6(D) == 1) goto ; else goto ; : : # prephitmp_41 = PHI <-1(OVF)(2), 2(3)> ... _3 = (unsigned short) prephitmp_41; _30 = _3 + 65535; _48 = (sizetype) _30; here and the loop is guarded with : # i_28 = PHI if (prephitmp_41 > 0) there is a pre-existing issue of a (OVF) constant in the IL (that's a no-no) and a missed jump-threading to expose the constant. There is also range info on the size argument of the memmove at expansion time: # RANGE [1, 2] NONZERO 3 _47 = _48 + 1; __builtin_memmove (_36, _33, _47); but we don't seem to have a target/middle-end expander for BUILT_IN_MEMMOVE. So that's a missed optimization there. Without loop distribution we fail to peel the inner loop as well (on the tree level), because Loop 2 iterates at most 32767 times. so we fail to compute a proper upper bound. The very same issue is present during loop distribution so it can't know the loop iterates only 1 or 2 times. Apart from special-casing this memmove in RTL expansion we could also enhance the memory builtin folders (in gimple-fold.c) to honor range information and in this case expand the memmove to something more optimal, like if (_47 == 1) *_36 = *_33; else *(unsigned short *)_36 = *(unsigned short *)_33; of course creating control-flow here is not expected (so dealing with this at RTL expansion time is easier). Thus confirmed - but applies to similar loops (niter bound not precise) before the SCEV changes.