[Bug middle-end/61762] failure to optimize memcpy from constant string

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-07-10
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I noticed elsewhere that we don't optimize

  static const char string[8] = "Private";
  unsigned int _2;

  <bb 2>:
  _2 = MEM[(char * {ref-all})&string];

to

  _2 = VIEW_CONVERT_EXPR <unsigned int> ("Private");


Mine.

Note that when not expanding the memcpy to a plain assignment in GIMPLE
GCC will likely do the "right" thing.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even if you change this at the GIMPLE level, we still should check why
expansion doesn't DTRT here.  expand_builtin_memcpy has already all the needed
store_by_pieces stuff.  Let me have a look at that.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 10 Jul 2014, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Even if you change this at the GIMPLE level, we still should check why
> expansion doesn't DTRT here.  expand_builtin_memcpy has already all the needed
> store_by_pieces stuff.  Let me have a look at that.

But it's expanded from an assignment, not a memcpy

[Bug middle-end/61762] failure to optimize memcpy from constant string

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, no, we've optimized the memcpy to the assignment and so we don't go through
expand_builtin_memcpy then that would be able to handle this.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Jul 25 07:44:57 2014
New Revision: 213045

URL: https://gcc.gnu.org/viewcvs?rev=213045&root=gcc&view=rev
Log:
2014-07-25  Richard Biener  <rguenther@suse.de>

    PR middle-end/61762
    PR middle-end/61894
    * fold-const.c (native_encode_int): Add and handle offset
    parameter to do partial encodings of expr.
    (native_encode_fixed): Likewise.
    (native_encode_real): Likewise.
    (native_encode_complex): Likewise.
    (native_encode_vector): Likewise.
    (native_encode_string): Likewise.
    (native_encode_expr): Likewise.
    * fold-const.c (native_encode_expr): Add offset parameter
    defaulting to -1.
    * gimple-fold.c (fold_string_cst_ctor_reference): Remove.
    (fold_ctor_reference): Handle all reads from tcc_constant
    ctors.

    * gcc.dg/pr61762.c: New testcase.
    * gcc.dg/fold-cstring.c: Likewise.
    * gcc.dg/fold-cvect.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/fold-cstring.c
    trunk/gcc/testsuite/gcc.dg/fold-cvect.c
    trunk/gcc/testsuite/gcc.dg/pr61762.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/fold-const.h
    trunk/gcc/gimple-fold.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.10.0

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ro at gcc dot gnu.org
         Resolution|FIXED                       |---

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
The pr61762.c testcase FAILs on SPARC:

FAIL: gcc.dg/pr61762.c scan-tree-dump-not release_ssa "Private"

  Rainer

[Bug middle-end/61762] failure to optimize memcpy from constant string

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33196&action=edit
-fdump-tree-release_ssa dump on sparc-sun-solaris2.11

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
The memcpy is not inlined on SPARC because sufficient alignment of the source
cannot be guaranteed.  This comes before the chance to eventually replace
that read by a compile-time read from the constant initializer (making
alignment a non-issue).  I'll see what we can do here.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 33218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33218&action=edit
patch

I have a patch but as the relevant folding already triggers during C parsing it
is too early for the cgraph code to see the constant initializer ... (well, on
x86_64).

But well, all this memory builtin folding should move to GIMPLE anyway...

Patch attached, it may still help SPARC passing the testcase.

(side-note - instead of the current fold_constant_aggregate_ref I'd like to
see a fold_constant_read (type, ptr) API that is, not require us building a
memory reference)

[Bug middle-end/61762] failure to optimize memcpy from constant string

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
[...]
> Patch attached, it may still help SPARC passing the testcase.

The patch doesn't make a difference, unfortunately.

    Rainer

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #11)
> > --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
> [...]
> > Patch attached, it may still help SPARC passing the testcase.
> 
> The patch doesn't make a difference, unfortunately.

It does, but only during the "fab" pass.  The issue is that when nothing
changes the IL we don't try re-folding and during gimplification (where
we unconditionally fold) we can't seem to get at the CTOR.

Honza agrees this is a bug in ctor_for_folding.

Richard.

> 	Rainer
>From gcc-bugs-return-457547-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 01 12:26:18 2014
Return-Path: <gcc-bugs-return-457547-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15651 invoked by alias); 1 Aug 2014 12:26:17 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15150 invoked by uid 48); 1 Aug 2014 12:26:11 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61762] failure to optimize memcpy from constant string
Date: Fri, 01 Aug 2014 12:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
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: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61762-4-IeYYoyXldA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61762-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61762-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-08/txt/msg00044.txt.bz2
Content-length: 802

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida762

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Does the following additional patch fix the existing testcase?

Index: varpool.c
==================================================================--- varpool.c   (revision 213342)
+++ varpool.c   (working copy)
@@ -413,8 +413,11 @@ ctor_for_folding (tree decl)
        }
     }

-  if ((!DECL_VIRTUAL_P (real_decl)
-       || DECL_INITIAL (real_decl) == error_mark_node
+  if (DECL_VIRTUAL_P (real_decl)
+      && DECL_INITIAL (real_decl) != error_mark_node)
+    return DECL_INITIAL (real_decl);
+
+  if ((DECL_INITIAL (real_decl) == error_mark_node
        || !DECL_INITIAL (real_decl))
       && (!node || !node->ctor_useable_for_folding_p ()))
     return error_mark_node;

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Argh.  Then we fall into the c_strlen wart to not break strlenopt...  which
means the fancy folding never triggers.

Oh well.  I guess simply XFAIL for strict-align targets.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Instead aligned the string.

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Aug  1 12:40:37 2014
New Revision: 213454

URL: https://gcc.gnu.org/viewcvs?rev=213454&root=gcc&view=rev
Log:
2014-08-01  Richard Biener  <rguenther@suse.de>

    PR middle-end/61762
    * gcc.dg/pr61762.c: Align the string to make the testcase work
    on strict-align targets.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr61762.c

[Bug middle-end/61762] failure to optimize memcpy from constant string

[froydnj at gcc dot gnu.org]

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

--- Comment #17 from Nathan Froyd <froydnj at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)
> Instead aligned the string.

This is kind of unfortunate, as the motivating testcase was something more
like:

...
  static const char string[] = "Private";
  unsigned int priv, riva, ivat, vate;
  memcpy(&priv, &string[0], sizeof(priv));
  memcpy(&riva, &string[1], sizeof(riva))
  memcpy(&ivat, &string[2], sizeof(ivat));
  memcpy(&vate, &string[3], sizeof(vate));
  /* proceed to use priv, riva, ivate, vate for comparisons */

So on strict-align targets, even if the source string was aligned (and that has
to be by user-declaration?) we wouldn't catch the latter three?

[Bug middle-end/61762] failure to optimize memcpy from constant string

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 1 Aug 2014, froydnj at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762
> 
> --- Comment #17 from Nathan Froyd <froydnj at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #15)
> > Instead aligned the string.
> 
> This is kind of unfortunate, as the motivating testcase was something more
> like:
> 
> ...
>   static const char string[] = "Private";
>   unsigned int priv, riva, ivat, vate;
>   memcpy(&priv, &string[0], sizeof(priv));
>   memcpy(&riva, &string[1], sizeof(riva))
>   memcpy(&ivat, &string[2], sizeof(ivat));
>   memcpy(&vate, &string[3], sizeof(vate));
>   /* proceed to use priv, riva, ivate, vate for comparisons */
> 
> So on strict-align targets, even if the source string was aligned (and that has
> to be by user-declaration?) we wouldn't catch the latter three?

Yes - or "maybe".  I will still implement the optimization (see the
patch) but it only triggers very late due to the c_strlen wart.

OTOH on strict-align targets you get the memcpy expanded which
means it's expanded inline if the target likes it to.