public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dorit at il dot ibm dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/18181] New: vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop Date: Wed, 27 Oct 2004 15:04:00 -0000 [thread overview] Message-ID: <20041027150430.18181.dorit@il.ibm.com> (raw) The loop peeling mechanism in the vectorizer (which is used to force alignment of stores - by peeling the first few iterations, and to support unknown loop bound - by peeling te last few iterations) does not handle correctly the case where a loop invariant is used after the loop; there are two problems: - When updating ssa-names the peeling utility assumes that anything that needs to be considered has a phi node at the loop header (which is not the case for loop invariants). - The peeling utility creats a path that did not exist before - from the loop prolog to the loop exit - and there is no value to assign for this variable on this path (as it is only defined inside the loop). This situation should rarely occur, but it did come up in the following case (complete testcase attached in http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00981.html): for i for j a[i][j]= [i+1][j] This is represented as follows: outer_loop_start i = phi (0, i') inner_loop_start j = phi (0, j') k = i + 1 a[i][j] = a[k][j] j' = j + 1 inner_loop_end i' = phi (k) k is the invariant defined in the inner-loop and used after the inner-loop (it was actually moved into the inner loop by PRE...). This problem does not show up currently because it needs Devang's dependence- distance patch (without it the vectorizer does not attempt to vectorize this loop). But as soon as his patch goes in - http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01046.html, the problem in this testcase will show up. A patch to solve this is in the works. -- Summary: vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dorit at il dot ibm dot com ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.0.0 GCC host triplet: powerpc-apple-darwin7.0.0 GCC target triplet: powerpc-apple-darwin7.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
next reply other threads:[~2004-10-27 15:04 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-10-27 15:04 dorit at il dot ibm dot com [this message] 2004-11-04 9:17 ` [Bug tree-optimization/18181] " dorit at il dot ibm dot com 2004-11-04 13:43 ` pinskia at gcc dot gnu dot org 2004-11-04 14:45 ` dorit at il dot ibm dot com 2004-11-19 19:40 ` cvs-commit at gcc dot gnu dot org 2004-11-19 20:14 ` pinskia 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=20041027150430.18181.dorit@il.ibm.com \ --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).