public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-65450-4-rrqrXy7FxQ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65450-4@http.gcc.gnu.org/bugzilla/>

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).


  parent reply	other threads:[~2015-03-17 18:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17  9:37 [Bug fortran/65450] New: [5.0 " ubizjak at gmail dot com
2015-03-17  9:38 ` [Bug fortran/65450] " ubizjak at gmail dot com
2015-03-17 10:00 ` ubizjak at gmail dot com
2015-03-17 10:14 ` dominiq at lps dot ens.fr
2015-03-17 10:22 ` ubizjak at gmail dot com
2015-03-17 10:39 ` jakub at gcc dot gnu.org
2015-03-17 12:42 ` trippels at gcc dot gnu.org
2015-03-17 12:44 ` trippels at gcc dot gnu.org
2015-03-17 12:57 ` dominiq at lps dot ens.fr
2015-03-17 13:24 ` jakub at gcc dot gnu.org
2015-03-17 14:15 ` [Bug fortran/65450] [4.9 5.0 " ubizjak at gmail dot com
2015-03-17 18:06 ` jakub at gcc dot gnu.org [this message]
2015-03-17 21:29 ` [Bug fortran/65450] [4.9/5 " jakub at gcc dot gnu.org
2015-03-18  9:00 ` jakub at gcc dot gnu.org
2015-03-18 10:49 ` [Bug tree-optimization/65450] " jakub at gcc dot gnu.org
2015-03-18 11:33 ` rguenth at gcc dot gnu.org
2015-03-18 13:29 ` rguenth at gcc dot gnu.org
2015-03-18 13:54 ` jakub at gcc dot gnu.org
2015-03-18 13:56 ` [Bug tree-optimization/65450] [4.9 " jakub at gcc dot gnu.org
2015-06-03 15:28 ` jakub at gcc dot gnu.org
2015-06-03 21:43 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-65450-4-rrqrXy7FxQ@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).