public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized Date: Tue, 25 Aug 2015 08:11:00 -0000 [thread overview] Message-ID: <bug-37021-4-qHt0wZ0C5o@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-37021-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Bill Schmidt from comment #20) > We still don't vectorize the original code example on Power. It appears > that this is being disabled because of an alignment issue. The data > references are being rejected by: > > product.f:9:0: note: can't force alignment of ref: REALPART_EXPR > <*a.0_24[_50]> > > and similar for the other three DRs. This happens due to this code in > vect_compute_data_ref_alignment: > > if (base_alignment < TYPE_ALIGN (vectype)) > { > /* Strip an inner MEM_REF to a bare decl if possible. */ > if (TREE_CODE (base) == MEM_REF > && integer_zerop (TREE_OPERAND (base, 1)) > && TREE_CODE (TREE_OPERAND (base, 0)) == ADDR_EXPR) > base = TREE_OPERAND (TREE_OPERAND (base, 0), 0); > > if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype))) > { > if (dump_enabled_p ()) > { > dump_printf_loc (MSG_NOTE, vect_location, > "can't force alignment of ref: "); > dump_generic_expr (MSG_NOTE, TDF_SLIM, ref); > dump_printf (MSG_NOTE, "\n"); > } > return true; > } > > Here TYPE_ALIGN (vectype) is 128 (Power vectors are normally aligned on a > 128-bit value), and base_alignment is 64. a.0 is defined as: > > complex(kind=8) [0:D.1831] * restrict a.0; > > In both ELFv1 and ELFv2 ABIs for Power, a complex type is defined to have > the same alignment as the underlying type. So "complex double" has 8-byte > alignment. > > On earlier versions of Power, the decision is fine, because unaligned > accesses are expensive prior to POWER8. With POWER8, though, an unaligned > access will (most of the time) perform as well as an aligned access. So > ideally we would like to teach the vectorizer to allow vectorization here. > > It seems like vect_supportable_dr_alignment ought to be considered as part > of the SLP vectorization decision here, rather than just comparing the base > alignment with the vector type alignment. Adding a check for that allows > things to get a little further, but we still don't vectorize the block. (I > haven't yet looked into why, but I assume more needs to be done downstream > to handle this case.) > > My understanding of the vectorizer is not yet very deep, so before going too > far down the wrong path, I'd like your opinion on the best approach to > fixing the problem. Thanks! I see it only failing due to cost issues (tried ppc64le and -mcpu=power8). The unaligned loads cost 3 and we end up with t.f90:8:0: note: Cost model analysis: Vector inside of loop cost: 40 Vector prologue cost: 8 Vector epilogue cost: 4 Scalar iteration cost: 12 Scalar outside cost: 6 Vector outside cost: 12 prologue iterations: 0 epilogue iterations: 0 t.f90:8:0: note: cost model: the vector iteration cost = 40 divided by the scalar iteration cost = 12 is greater or equal to the vectorization factor = 1. Note that we are (still) not very good in estimating the SLP cost as we account 4 vector loads here (because we essentially will end up with 4 different permutations used), so the "unaligned" part is accounted for too much and likely the permutation cost as well. Both are a limitation of the SLP data structures and not easily fixable. With -fvect-cost-model=unlimited I see both loops vectorized. > Bill
next prev parent reply other threads:[~2015-08-25 8:11 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-37021-4@http.gcc.gnu.org/bugzilla/> 2011-03-25 11:49 ` sebastian.hegler@tu-dresden.de 2011-03-25 12:27 ` sebastian.hegler@tu-dresden.de 2011-03-25 13:13 ` rguenther at suse dot de 2012-07-13 8:46 ` rguenth at gcc dot gnu.org 2013-02-13 15:58 ` rguenth at gcc dot gnu.org 2013-03-27 10:39 ` rguenth at gcc dot gnu.org 2013-03-27 10:40 ` rguenth at gcc dot gnu.org 2013-04-07 13:18 ` dominiq at lps dot ens.fr 2015-05-12 11:56 ` rguenth at gcc dot gnu.org 2015-06-10 10:45 ` rguenth at gcc dot gnu.org 2015-08-25 8:11 ` rguenth at gcc dot gnu.org [this message] 2015-08-27 22:09 ` wschmidt at gcc dot gnu.org 2015-08-28 7:46 ` rguenther at suse dot de 2015-08-28 13:20 ` wschmidt at gcc dot gnu.org 2015-08-28 13:31 ` wschmidt at gcc dot gnu.org 2015-10-22 10:03 ` rguenth at gcc dot gnu.org 2023-07-21 12:28 ` rguenth at gcc dot gnu.org 2008-08-04 17:57 [Bug tree-optimization/37021] New: " rguenth at gcc dot gnu dot org 2008-08-04 17:59 ` [Bug tree-optimization/37021] " rguenth at gcc dot gnu dot org 2008-08-19 15:31 ` rguenth at gcc dot gnu dot org 2009-01-21 15:43 ` rguenth at gcc dot gnu dot org 2009-01-23 15:33 ` rguenth at gcc dot gnu dot org 2009-01-23 15:36 ` rguenth at gcc dot gnu dot org 2009-01-25 9:13 ` irar at il dot ibm dot com 2009-01-25 11:04 ` rguenther at suse dot de 2009-01-25 12:17 ` irar at il dot ibm dot com 2009-01-27 12:40 ` dorit at gcc dot gnu dot 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-37021-4-qHt0wZ0C5o@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: linkBe 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).