public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "eyalroz1 at gmx dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/112612] New: [Missed Optimization] Holding on the loop variable rather than a derived value which can replace it Date: Sat, 18 Nov 2023 21:04:29 +0000 [thread overview] Message-ID: <bug-112612-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112612 Bug ID: 112612 Summary: [Missed Optimization] Holding on the loop variable rather than a derived value which can replace it Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz1 at gmx dot com Target Milestone: --- Consider the following function: void foo(int* __restrict__ a) { int i, val; for (i = 0; i < 100; i++) { val = 2 * i; a[i] = val; } } When compiling it for x86_64 with -O3 -fno-unroll-loops -fno-tree-vectorize, GCC 7.2 used to give: foo: xor eax, eax .L2: mov DWORD PTR [rdi], eax add eax, 2 add rdi, 4 cmp eax, 200 jne .L2 rep ret which was rather wasteful, as eax and rdi - eax are linearly related. With GCC 13.2 or trunk on GodBolt as of today, this improves, but not really: foo: xor eax, eax .L2: lea edx, [rax+rax] mov DWORD PTR [rdi+rax*4], edx add rax, 1 cmp rax, 100 jne .L2 ret So, we don't increment two things; but - we do have an addition-via-lea in each iteration. Is that really necessary? I mean, instead of keeping the i variable (in rax), we could keep v = 2 * i, and that's good enough for both addressing and condition checking. Indeed, clang 17 emits: foo: # @foo xor eax, eax .LBB0_1: # =>This Inner Loop Header: Depth=1 mov dword ptr [rdi + 2*rax], eax add rax, 2 cmp rax, 200 jne .LBB0_1 ret which is almost the same, except that it holds v = 2 * i rather than i. (clang has produced this code since v3.0.0 at least.) GodBolt link: https://gcc.godbolt.org/z/MjzTbr831 Originally discussed in this SO question: https://stackoverflow.com/q/48354636/1593077
next reply other threads:[~2023-11-18 21:04 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-18 21:04 eyalroz1 at gmx dot com [this message] 2023-11-18 21:41 ` [Bug tree-optimization/112612] " pinskia at gcc dot gnu.org 2023-11-18 23:54 ` eyalroz1 at gmx dot com 2023-11-20 9:42 ` 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-112612-4@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).