public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steven Bosscher <stevenb@suse.de>
To: gcc@gcc.gnu.org
Subject: On -ftrapv vs. libcalls...
Date: Tue, 31 Aug 2004 13:50:00 -0000	[thread overview]
Message-ID: <200408221254.28457.stevenb@suse.de> (raw)

Hi,

Could anyone please help me get some insight into the following
problem.

Consider,

int
mulv(int a, int b)
{
  return a * b;
}

compiled with -ftrapv.  This gives the following code in the .rtl dump
on ia64.

(insn 18 17 19 1 (set (reg:DI 120 out0)
        (reg:DI 345)) -1 (nil)
    (insn_list:REG_LIBCALL 21 (nil)))

(insn 19 18 20 1 (set (reg:DI 121 out1)
        (reg:DI 347)) -1 (nil)
    (nil))

(call_insn/u 20 19 21 1 (parallel [
            (set (reg:DI 8 r8)
                (call (mem:DI (symbol_ref:DI ("__mulvdi3") [flags 0x41]) [0 S8 A64])
                    (const_int 1 [0x1])))
            (clobber (reg:DI 320 b0))
            (clobber (scratch:DI))
            (clobber (scratch:DI))
        ]) -1 (nil)
    (expr_list:REG_EH_REGION (const_int -1 [0xffffffffffffffff])
        (nil))
    (expr_list (use (reg:DI 1 r1))
        (expr_list (use (reg:DI 121 out1))
            (expr_list (use (reg:DI 120 out0))
                (nil)))))

(insn 21 20 22 1 (set (reg:DI 349)
        (reg:DI 8 r8)) -1 (nil)
    (insn_list:REG_RETVAL 18 (expr_list:REG_EQUAL (mult:DI (reg:DI 345)
                (reg:DI 347))
            (nil))))


Note the __mulvdi3 libcall.  At the first opportunity to do so, the
first jump pass, we collapse it to a normal MULT insn:

(insn 16 15 17 0 (set (reg:SI 348 [ b ])
        (mem/i:SI (reg/f:DI 344) [0 b+0 S4 A32])) -1 (nil)
    (nil))

(insn 17 16 21 0 (set (reg:DI 347 [ b ])
        (sign_extend:DI (reg:SI 348 [ b ]))) -1 (nil)
    (nil))

(insn 21 17 22 0 (set (reg:DI 349)
        (mult:DI (reg:DI 345 [ a ])
            (reg:DI 347 [ b ]))) 105 {muldi3} (nil)
    (nil))
(insn 22 21 23 0 (set (reg:SI 339 [ T.0 ])
        (subreg:SI (reg:DI 349) 0)) -1 (nil)
    (nil))

[ this also happens on x86 and amd64, but there the problem is not
  as obvious - apparently ia64 doesn't even have that function in
  libgcc so it causes a link failure without libcall notes.  ]

Without -ftrapv we never emit it, we just always generate a normal
MULT insn, never the libcall:

(insn 14 13 15 1 (set (reg:SI 345)
        (mem/i:SI (reg/f:DI 335 virtual-stack-vars) [0 a+0 S4 A32])) -1 (nil)
    (nil))

(insn 15 14 16 1 (set (reg:SI 346)
        (mem/i:SI (reg/f:DI 344) [0 b+0 S4 A32])) -1 (nil)
    (nil))

(insn 16 15 17 1 (set (reg:SI 339 [ T.0 ])
        (mult:SI (reg:SI 345)
            (reg:SI 346))) -1 (nil)
    (nil))

I'm trying to get rid of libcall notes, so I would really like to know
and understand why we emit a libcall with -ftrapv.  With my patch, we
cannot fold the libcall anymore, so it's a show stopper for removing
libcalls that we emit the (apparently?) unnecessary libcall.

Is there a way to avoid emiting a libcall in this case?

Not emitting the libcall would be good in any case since it would
improve the initially generated RTL with -ftrapv...

Gr.
Steven


             reply	other threads:[~2004-08-31 13:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 13:50 Steven Bosscher [this message]
2004-08-31 14:48 ` Zdenek Dvorak
2004-08-31 19:18   ` James E Wilson
2004-09-01 12:12     ` Joern Rennecke
2004-08-31 18:28 ` Joern Rennecke
2004-08-31 20:21 ` Richard Henderson

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=200408221254.28457.stevenb@suse.de \
    --to=stevenb@suse.de \
    --cc=gcc@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).