From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26674 invoked by alias); 1 Jul 2005 17:15:45 -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 26658 invoked by uid 22791); 1 Jul 2005 17:15:41 -0000 Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 01 Jul 2005 17:15:41 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc11) with SMTP id <2005070117153801300svdn4e>; Fri, 1 Jul 2005 17:15:38 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 01 Jul 2005 17:15:00 -0000 Subject: Re: potential simple loop optimization assistance strategy? From: Paul Schlie To: Gabriel Dos Reis CC: GCC Development Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00039.txt.bz2 > From: Gabriel Dos Reis > | Paul Schlie writes: > | As in general it seems that as the compiler knows what it needs to know to > | enable ideal loop optimization, why not simply have it assert: if it knew x, > | then it could do y? For example, if given something like: > | > | for (i = x; i < y; i++){ ... } > | > | Where it may not be known statically if x < y, or what (y - x) % N may be; > | therefore possibly difficult to ideally optimize. Where then instead of > | assuming something that may not be factual by default, it could generate a > | warning indicating that the loop may be further optimized if it knew that > | x < y, and/or (y - x) % N == 0. Where then the programmer could then choose > | to warrant it by preconditioning the loop: > | > | assert((x < y) && ((y - x) % 4)); // which could throw an exception. > | > | for ((i = x; i < y; i++){ ... } > | > | Where although it would require run-time code, it's overhead should be > | insignificant if the benefit of the optimization were truly significant; > > I would not predicate the transformation on that assumption > (negligible cost of assertion). That could happen in an inner tight > loop. > > What we need is a balance that does not require too much of work from > the compiler -- because otherwise, it won't happen. Understood, but can't help but wonder how many nested loops realalisticly have nested data dependancies; but none the less, I guess all it takes is one important one to justify worrying about it. And agree it would be nice if static assertions could be made in some reasonable way embedded in the code.