public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access Date: Tue, 12 Dec 2023 14:26:55 +0000 [thread overview] Message-ID: <bug-112736-4-XWD5mqzFWx@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-112736-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736 --- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:6d0b0806eb638447c3184c59d996c2f178553d45 commit r14-6459-g6d0b0806eb638447c3184c59d996c2f178553d45 Author: Richard Biener <rguenther@suse.de> Date: Mon Dec 11 14:39:48 2023 +0100 tree-optimization/112736 - avoid overread with non-grouped SLP load The following aovids over/under-read of storage when vectorizing a non-grouped load with SLP. Instead of forcing peeling for gaps use a smaller load for the last vector which might access excess elements. This builds upon the existing optimization avoiding peeling for gaps, generalizing it to all gap widths leaving a power-of-two remaining number of elements (but it doesn't replace or improve that particular case at this point). I wonder if the poly relational compares I set up are good enough to guarantee /* remain should now be > 0 and < nunits. */. There is existing test coverage that runs into /* DR will be unused. */ always when the gap is wider than nunits. Compared to the existing gap == nunits/2 case this only adjusts the load that will cause the overrun at the end, not every load. Apart from the poly relational compares it should reliably cover these cases but I'll leave it for stage1 to remove. PR tree-optimization/112736 * tree-vect-stmts.cc (vectorizable_load): Extend optimization to avoid peeling for gaps to handle single-element non-groups we now allow with SLP. * gcc.dg/torture/pr112736.c: New testcase.
next prev parent reply other threads:[~2023-12-12 14:26 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-27 22:30 [Bug tree-optimization/112736] New: " kristerw at gcc dot gnu.org 2023-11-27 22:44 ` [Bug tree-optimization/112736] [14 Regression] " pinskia at gcc dot gnu.org 2023-11-28 12:10 ` rguenth at gcc dot gnu.org 2023-12-11 13:43 ` rguenth at gcc dot gnu.org 2023-12-12 14:26 ` cvs-commit at gcc dot gnu.org [this message] 2023-12-12 14:27 ` rguenth 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-112736-4-XWD5mqzFWx@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).