public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/48580] missed optimization: integer overflow checks Date: Wed, 13 Apr 2011 12:11:00 -0000 [thread overview] Message-ID: <bug-48580-4-R8ima4Bjw0@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-48580-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011.04.13 12:11:47 CC| |rguenth at gcc dot gnu.org Component|rtl-optimization |middle-end Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-13 12:11:47 UTC --- I too would see it as two pieces, pattern matching on trees to produce a canonical builtin call and RTL expansion of that for optimal target code generation (where I don't know whether we can do better than using UNSPECs). Note that usually you also want to use the result of the multiplication (if it didn't overflow), and using just a single multiplication might be even more complicated (if we need to go the UNSPEC way). For the latter reasons I think the builtins should be sth like __builtin_smul_ovfl_p (multiplication-result, op0, op1), thus pass in the multiplication result and keep the multiplication itself in the IL to also allow for regular optimizations to work on them. If the multiplication is just used as the builtin call argument expansion can get rid of it. The set of builtins with defined behavior is still useful, if not only to allow mixing of wrapv/trapv/... operations in C source. But it isn't exactly the form I'd like the operations to reside in the IL. Pattern-matching the multiplication overflow code can be tricky because of the various ways the handling of zero operands can be implemented. Implementing this entirely on the RTL side seems very tricky to me.
next prev parent reply other threads:[~2011-04-13 12:11 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-12 18:36 [Bug rtl-optimization/48580] New: " zackw at panix dot com 2011-04-12 20:18 ` [Bug rtl-optimization/48580] " joseph at codesourcery dot com 2011-04-12 20:40 ` zackw at panix dot com 2011-04-12 20:52 ` joseph at codesourcery dot com 2011-04-12 21:03 ` zackw at panix dot com 2011-04-12 21:04 ` zackw at panix dot com 2011-04-12 21:10 ` joseph at codesourcery dot com 2011-04-12 21:16 ` joseph at codesourcery dot com 2011-04-13 12:11 ` rguenth at gcc dot gnu.org [this message] 2011-04-13 12:46 ` [Bug middle-end/48580] " joseph at codesourcery dot com 2011-04-13 17:44 ` svfuerst at gmail dot com 2011-06-20 9:47 ` jsm28 at gcc dot gnu.org 2011-10-05 12:44 ` jules at gcc dot gnu.org 2011-10-05 13:08 ` jules at gcc dot gnu.org 2011-10-05 15:20 ` joseph at codesourcery dot com 2013-02-02 14:03 ` Martin.vGagern at gmx dot net 2013-02-02 17:02 ` noloader at gmail dot com 2013-02-02 18:54 ` Martin.vGagern at gmx dot net 2013-02-02 21:59 ` zackw at panix dot com 2013-02-02 22:08 ` Martin.vGagern at gmx dot net 2013-05-19 13:04 ` glisse at gcc dot gnu.org 2014-08-24 7:06 ` Martin.vGagern at gmx dot net 2021-08-15 11:45 ` pinskia at gcc dot gnu.org 2021-08-15 11:49 ` pinskia at gcc dot gnu.org 2021-10-22 22:18 ` pinskia at gcc dot gnu.org 2023-08-09 22:29 ` pinskia 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-48580-4-R8ima4Bjw0@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).