From: Johan Danielsson <joda@kth.se>
To: gcc-help@gcc.gnu.org
Subject: optimization issues in gcc 4,8
Date: Wed, 22 Jan 2014 20:57:00 -0000 [thread overview]
Message-ID: <CAESKgcjBBo9EihmO0LFh1PTCS5jxJTsiJ9kWaDs=ZkPMuEaVrA@mail.gmail.com> (raw)
Hello,
I'm looking at moving GCC from 4.5 to 4.8 for a custom CPU. For the
most part GCC 4.8 produces better code (smaller, which is mostly what
matters in my case). There are however some parts where it does
worse. Trying to isolate some of these cases I've come across the
following.
I have the this function (which is really part of a larger context),
multiplying two signed 32-bit integers returning a 64-bit signed
integer:
long long mul_32_64(int a, int b)
{
unsigned int lo;
unsigned int hi;
__asm__("muls.w %0, %2, %3\n"
"mulshi.w %1, %2, %3"
: "=&r"(lo), "=r"(hi)
: "r"(a), "r"(b));
return (long long)(((unsigned long long)hi << 32) | lo);
}
In this CPU r0..r3 are used for arguments, and are also temporary
registers.
GCC 4.5.3 (-Os) produces the following assembler:
mul_32_64:
psh.h 1,4 ; save r4
mov.h r3,r0
muls.w r4, r1, r2 ; mul a and b, put result in r4
mulshi.w r2, r1, r2 ; ... and the upper half in r2
sw.h 0(r3),r4 ; store low part to return value
sw.h 4(r0),r2 ; ... and high
popr.h 1,4 ; restore r4 and return
This is close to optimal, except that if it had used r3 instead of r4
it would not have had to save any registers at all. GCC 4.7.3 gives
the same result.
Now this is what GCC 4.8.2 thinks about this:
mul_32_64:
psh.h 6,24
mov.h r3,r0
muls.w r4, r1, r2
mulshi.w r1, r1, r2
mov.h r2,r4
ldi.h r4,0
mov.h r5,r4
mov.h r4,r1
mov.h r6,r5
mov.h r7,r1
mov.h r9,r5
mov.h r8,r2
sw.h 0(r3),r2
sw.h 4(r3),r1
popr.h 6,24
Clearly it has given up on optimizing this. Looking at the RTL output,
the step that removes all register shuffling is fwprop, but for 4.8
this does nothing.
So my question is really what is causing this. Is it a bug in GCC 4.8,
is there some misconfiguration in the backend that is only hitting
some functions, or something else. How do I debug this?
/Johan
reply other threads:[~2014-01-22 20:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAESKgcjBBo9EihmO0LFh1PTCS5jxJTsiJ9kWaDs=ZkPMuEaVrA@mail.gmail.com' \
--to=joda@kth.se \
--cc=gcc-help@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).