From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8255 invoked by alias); 9 Jul 2007 13:01:50 -0000 Received: (qmail 8229 invoked by uid 22791); 9 Jul 2007 13:01:48 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jul 2007 13:01:46 +0000 Received: by py-out-1112.google.com with SMTP id a29so2201657pyi for ; Mon, 09 Jul 2007 06:01:44 -0700 (PDT) Received: by 10.64.241.3 with SMTP id o3mr4620451qbh.1183986104102; Mon, 09 Jul 2007 06:01:44 -0700 (PDT) Received: from scientist.local ( [68.179.81.66]) by mx.google.com with ESMTP id p4sm6068926qba.2007.07.09.06.01.38 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Jul 2007 06:01:43 -0700 (PDT) Message-ID: <469231B2.3010503@gnu.org> Date: Mon, 09 Jul 2007 13:12:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eric Botcazou CC: Paolo Bonzini , Andrew Pinski , gcc-patches@gcc.gnu.org, Mark Mitchell Subject: Re: PR/32004, tree-ssa caused in/out asm constraints to often need reloads References: <468CC82F.2060702@lu.unisi.ch> <200707090748.59581.ebotcazou@adacore.com> <469228F7.6020601@gnu.org> <200707091455.31718.ebotcazou@adacore.com> In-Reply-To: <200707091455.31718.ebotcazou@adacore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-07/txt/msg00790.txt.bz2 Eric Botcazou wrote: >> Actually it is fixed by this trivial patch. Ok for 4.2/4.1? > > This patch is *not* trivial. The RTL dataflow engine in flow.c has known > quirks and we should be conservative in changing how it is invoked. That's why I'm invoking in GLOBAL_RM_NOTES rather than LOCAL which ought to be enough. That's conservativeness. I do believe the patch is trivial (note I didn't say obvious) if you investigated the failure mode. The problem is that reg_equiv_regs is set when REG_N_REFS is 2 and in this case we have more than 2 after the new pass. The patch is in testing now, and the gcc directory has already been tested fully on both the 4.1 and 4.2 branches. If you want me to revert the patch on 4.1 and apply the combination in a few days, after letting it stay on 4.2 for a while, I can do that. Otherwise, I would very much prefer fixing PR21291/PR32004, which is as bad a regression as the one I introduced. Of course, I'm not meaning I'm *not* sorry to have introduced a regression. Paolo