From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24551 invoked by alias); 13 Apr 2011 12:11:59 -0000 Received: (qmail 24540 invoked by uid 22791); 13 Apr 2011 12:11:57 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Apr 2011 12:11:49 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/48580] missed optimization: integer overflow checks X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Component Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 13 Apr 2011 12:11:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01331.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Richard Guenther 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 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.