public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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).