From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28082 invoked by alias); 29 Jun 2005 18:01:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28073 invoked by uid 22791); 29 Jun 2005 18:01:28 -0000 Received: from h-68-164-203-246.nycmny83.covad.net (HELO dberlin.org) (68.164.203.246) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 29 Jun 2005 18:01:28 +0000 Received: from [127.0.0.1] (HELO localhost) by dberlin.org (CommuniGate Pro SMTP 4.3.4) with ESMTP id 8184478; Wed, 29 Jun 2005 14:01:20 -0400 Subject: Re: Do C++ signed types have modulo semantics? From: Daniel Berlin To: Steven Bosscher Cc: Ulrich Weigand , gcc@gcc.gnu.org, Robert Dewar , Mark Mitchell , Michael Veksler , Paul Koning , gdr@integrable-solutions.net, nathan@codesourcery.com In-Reply-To: <200506291846.34864.stevenb@suse.de> References: <200506281202.j5SC27s7024579@53v30g15.boeblingen.de.ibm.com> <200506281409.02246.stevenb@suse.de> <200506291846.34864.stevenb@suse.de> Content-Type: text/plain Date: Wed, 29 Jun 2005 18:01:00 -0000 Message-Id: <1120068079.7612.31.camel@linux-009002219098.watson.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01268.txt.bz2 On Wed, 2005-06-29 at 18:46 +0200, Steven Bosscher wrote: > On Tuesday 28 June 2005 14:09, Steven Bosscher wrote: > > On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote: > > > Steven Bosscher wrote: > > > > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's > > > > see how big the damage would be ;-) > > > > > > Please make sure to include a 64-bit target, where it actually makes any > > > difference. (I recall performance degradations of 20-30% in some > > > SPECfp cases from getting induction variable reduction wrong ...) > > > > Yeah, I'm testing on an AMD64 box, both 64 bits and 32 bits. > > And the numbers are, only those tests that build in both cases, > left is base == "-O2", right is peak == "-O2 -fwrapv: None of these numbers actually include real loop transformations that often take advantage of wrapping semantics, so it's not interesting. In fact, i'm surprised that the numbers are different *at all*. It's only heavy duty reordering things like vectorization, linear loop transforms, distribution, you name it, etc, that really want to know the number of iterations in a loop, etc that it makes any significant difference. So i would advise anyone arguing against turning on -fwrapv simply because it doesn't seem to hurt us at O2. And i'll again point out that the exact opposite is the default in every other compiler i'm aware of. XLC at O2 has qstrict_induction on by default (the equivalent), and warns the user when it sees a loop where it's making the assumption[1] The XLC people told me since they turned this on in 1998, they have had one real piece of code where it actually mattered, and that was a char induction variable. ICC does the same, though i don't think it bothers to warn. Open64 does the same, but no warning. Not sure about Sun CC, but i'd be very surprised if they did it. Personally, i only care about wrapping for induction variables. If you guys want to leave regular variables to do whatever, fine. But if you turn on this wrapping behavior, you have more or less given up any chance we have of performing heavy duty loop transforms on most real user code, even though the user doesn't actually give two shits about wrapping. --Dan [1] The manual points out the performance degradation using the option is quite severe. I've sent actual numbers privately to some people, but i don't want to make them public because i'm not sure the xlc folks would like it.