From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-480567-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 62598 invoked by alias); 17 Mar 2015 18:06:08 -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 60616 invoked by uid 48); 17 Mar 2015 18:06:03 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
Date: Tue, 17 Mar 2015 18:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65450-4-rrqrXy7FxQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65450-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65450-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/msg01711.txt.bz2

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I believe it is incorrect ALIGN info as can be seen in the
-fdump-tree-all-alias dumps.
Seems with current trunk on x86_64-linux and
-g -quiet -mtune=amdfam10 -O3 pr65450.f90
the problematic memory load which should have been movupd and is movapd instead
is using _3571:
  # ALIGN = 32, MISALIGN = 0
  vectp.499_3571 = vectp.499_1481 + 64;
which has been created by aprefetch pass from:
  # ALIGN = 32, MISALIGN = 0
  vectp.499_135 = vectp.499_1480 + 16;
which has been created by pcom pass from:
  # ALIGN = 32, MISALIGN = 0
  vectp.499_1480 = vectp.499_1481 + 16;
which has been created during vectorization by vect_create_data_ref_ptr ->
create_iv -> make_ssa_name for dr:
#(Data Ref: 
#  bb: 43 
#  stmt: _1095 = MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
#  ref: MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
#  base_object: MEM[(real(kind=8)[0:D.3649] *)_558];
#  Access function 0: {_1086 + 3, +, 1}_41
#)
- _1480 is indx_after_incr.
The base_object is indeed 32 byte aligned:
  # RANGE [-64424509440000, 60000] NONZERO 18446744073709551600
  _557 = _556 * 30000;
  # PT = { D.3692 } (nonlocal)
  # ALIGN = 32, MISALIGN = 0
  _558 = &u[_557];
- u is a common aligned to 32 bytes:
static real(kind=8) u[90000];
and 30000 is divisible by 16, and it is ARRAY_REF, so the offset from &u[0] is
a multiple of 128 bytes.  But that doesn't tell anything about what values
_1094 can have.
I see vect_create_addr_base_for_vector_ref already always overrides the
align/misalign info after duplicating DR_PTR_INFO, and so does bump_vector_ptr,
but vect_create_data_ref_ptr trusts DR_PTR_INFO.  But from what I can
understand, it is just the points to info, and alignment info in there is
solely for the base address, but not necessarily for the whole DR.
Richard, do you agree?  Now the question is what we can do here, if in all the
spots in vect_create_data_ref_ptr we should just set it to unknown alignment,
or if we can do better (and how).