From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26136 invoked by alias); 3 May 2002 23:54:04 -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 26042 invoked from network); 3 May 2002 23:54:02 -0000 Received: from unknown (HELO mail.kloo.net) (63.192.214.25) by sources.redhat.com with SMTP; 3 May 2002 23:54:02 -0000 Received: by mail.kloo.net (Postfix, from userid 500) id 4A4953B033D; Fri, 3 May 2002 16:46:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.kloo.net (Postfix) with ESMTP id 458E93B4378; Fri, 3 May 2002 16:46:03 -0700 (PDT) Date: Fri, 03 May 2002 16:54:00 -0000 From: tm To: Richard Henderson Cc: gcc@gcc.gnu.org, kazu@cs.umass.edu, joern.rennecke@superh.com Subject: Re: Post-register-allocation opportunitistic optimizer? In-Reply-To: <20020503162220.A6106@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-05/txt/msg00281.txt.bz2 On Fri, 3 May 2002, Richard Henderson wrote: > On Fri, May 03, 2002 at 03:49:58PM -0700, tm wrote: > > Imagine a situation in a basic block with two hard registers free. > > An analysis of the code reveals the following possible optimizations: > > > > optimization scratch hard regs RTX_COST > > opportunity required benefit > > ----------------------------------------------- > > #1 1 3 > > #2 1 5 > > #3 2 11 > > > > In this case, if you perform optimization #1 first, then there is only > > one hard register free, > > Stop. You are already incorrect. > > The register used in a peep2 will _only_ be used within that single > peephole pattern, thus it is dead after the matched sequence, thus > there are two free registers for _every_ matched sequence. Ah, I made a bad assumption. I understand this now. So we can naively emit long sequences of single shifts, and have peep2 clean it up for us later if hard registers are available. Nice! Toshi