From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1472 invoked by alias); 9 Nov 2007 12:15:49 -0000 Received: (qmail 1193 invoked by uid 48); 9 Nov 2007 12:15:39 -0000 Date: Fri, 09 Nov 2007 12:15:00 -0000 Message-ID: <20071109121539.1192.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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: 2007-11/txt/msg00777.txt.bz2 ------- Comment #2 from jakub at gcc dot gnu dot org 2007-11-09 12:15 ------- I think whether the modulus will be bigger or smaller is terribly hard to estimate. Really, if you file -Os regressions, you should at least compile the whole kernel and compare whether the resulting sizes, rather than cherry picking one example. E.g. on ppc64 computing modulus rather than doing the loop is definitely much shorter. IMHO if the kernel wants to avoid using modulus, it should just say so unsigned long long foobar(unsigned long long ns) { while(ns >= 1000000000L) { ns -= 1000000000L; asm ("" : "=r" (ns) : "0" (ns)); } return ns; } will do that just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34027