From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-384666-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24834 invoked by alias); 27 Feb 2012 16:25:36 -0000
Received: (qmail 24813 invoked by uid 22791); 27 Feb 2012 16:25:32 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Feb 2012 16:25:18 +0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
Date: Mon, 27 Feb 2012 16:42: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-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-52395-4-Fol4mrpghw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52395-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52395-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-02/txt/msg02600.txt.bz2

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

--- Comment #10 from Martin Jambor <jamborm at gcc dot gnu.org> 2012-02-27 16:25:15 UTC ---
(In reply to comment #4)
> Martin, can we make sure that 'base' as passed to build_ref_for_offset
> is not artificially constructed by any of its callers?  Thus, that it is
> at most the result of stripping some handled-component-refs from an
> existing reference tree (that was not wrapped inside an ADDR_EXPR) in the IL?

As you noticed in PR 52402 IPA-SRA code does not use this function and
IPA-CP only does so when the address argument is a global declaration,
which should be always handled well by expand, I hope.

However, I believe it's the plain ordinary SRA which can introduce,
accesses which the base did not have before.  Consider function foo in
the following testcase:

--------------------------------------------------
typedef long long __m128i __attribute__ ((__vector_size__ (16),
                      __may_alias__));
typedef unsigned int uint32_t;
extern void abort ();

typedef struct
{
  __m128i b;
  int a;
} s_1a;

typedef s_1a s_1m __attribute__((aligned(1)));

typedef struct
{
  char c;
  s_1m s;
} __attribute__((packed)) s_2;

void __attribute__((noinline, noclone))
foo (s_1m *p)
{
  __m128i v1 = {1,1};
  s_1a l;

  l = *p;
  l.b = v1;
  *p = l;
}

int
main (int argc, char **argv)
{
  __m128i v2 = {3,4};
  long long z[2];
  s_2 x;


  x.s.b = v2;
  foo (&x.s);
  __builtin_memcpy (&z, &x.s.b, sizeof (x.s.b));

  if (z[0] != 1 || z[1] != 1)
    abort ();

  return 0;
}
--------------------------------------------------

The original foo:

  l = *p_2(D);
  l.b = { 1, 1 };
  *p_2(D) = l;

is basically converted into (optimized dump):

  p_2(D)->b = { 1, 1 };

so we have introduced a non-BLKmode access into a base which did not
have it previously.  I am not sure whether this fits your definition
of base which was already there or not.  On the other hand, this
testcase passes with the patch from comment 6 (but fails with PR 50444
fix reverted) and SRA never creates anything more beastly than this,
i.e. forwarding scalar loads/stores across aggregate assignments.

Does that answer your question?