From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30321 invoked by alias); 17 Jun 2002 15:26:06 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 30300 invoked by uid 71); 17 Jun 2002 15:26:04 -0000 Date: Mon, 17 Jun 2002 09:37:00 -0000 Message-ID: <20020617152604.30299.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Richard Earnshaw Subject: Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0 Reply-To: Richard Earnshaw X-SW-Source: 2002-06/txt/msg00399.txt.bz2 List-Id: The following reply was made to PR target/7056; it has been noted by GNATS. From: Richard Earnshaw To: pb@nexus.co.uk Cc: gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com, jakub@gcc.gnu.org, mark@codesourcery.com Subject: Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0 Date: Mon, 17 Jun 2002 16:21:06 +0100 This was caused by Jakub's patch to fix pr/6086, hence the CC list. I think his patch is papering over a symptom rather than fixing the real problem in reload. That is, if you are going to allow (subreg (mem)) at all, then reload must handle it correctly, even if the mem has side-effects. In this case we should be making reload correctly spill the mem, rather than preventing the above RTL if the mem has side-effects. For a RISC architecture, like the PPC, I don't think it makes sense to allow subreg-mem in the first place. The ARM doesn't and I've generally found this to lead to better code than allowing it and then letting reload fix up the problems. In general these problems seem to come about because register_operand() allows subreg(reg-or-mem) and that seems daft. R.