From patchwork Sun Jan 11 11:40:24 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleg Endo X-Patchwork-Id: 427459 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6A86B140192 for ; Sun, 11 Jan 2015 22:40:59 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version; q=dns; s=default; b=Wu2Fl617X7+4zVMb 6y8hbFQh2FFDMZcOjpdDS+7TriInhIJP8ufjAEkKomdnMdJ2n5XOvT/b4obfxlHX AKfhb/CdIRTkYhp+NcqJjISMrfpR1ZZFIqC9sA7jRcXDtCG7BlrxeEv6CvjlHq4+ DFSwwTAPvNHSwAt601Mc0ljFuVw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version; s=default; bh=2x6R84hBKWOt+U2ZsQLAlu CVf0w=; b=PABCAkwctYAY3qRKzbU6RqBCtDdXOGGKpiDzp/scZ93DFTkNguvJdA 0jAf7qP7C6x802/BpTXitBs7Yi8AzFd9dkpIyQ8XLwKCy6m3DkpOksQOXKnm29+A 2PKd6hP8yMF5gzcRHZar26BBMWdaWEgxzjuU0uw16hyDOzh6sSgWc= Received: (qmail 32542 invoked by alias); 11 Jan 2015 11:40:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 32530 invoked by uid 89); 11 Jan 2015 11:40:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailout03.t-online.de Received: from mailout03.t-online.de (HELO mailout03.t-online.de) (194.25.134.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 11 Jan 2015 11:40:48 +0000 Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de [172.20.26.241]) by mailout03.t-online.de (Postfix) with SMTP id D09CB3CE928; Sun, 11 Jan 2015 12:40:43 +0100 (CET) Received: from [192.168.0.104] (SgLyzuZrrhsD2t+IhCKghw-RCg0V-jWHv9nupgd6Q05-lx1cKex2Klx8tIVAVM5Qws@[84.180.102.58]) by fwd12.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1YAGst-4Lb4sq0; Sun, 11 Jan 2015 12:40:43 +0100 Message-ID: <1420976424.2473.177.camel@yam-132-YW-E178-FTW> Subject: Re: [RFC PATCH] Handle sequence in reg_set_p From: Oleg Endo To: gcc-patches Cc: Jeff Law Date: Sun, 11 Jan 2015 12:40:24 +0100 In-Reply-To: <54AEF440.6070508@redhat.com> References: <1420719782.2473.122.camel@yam-132-YW-E178-FTW> <54AEF440.6070508@redhat.com> Mime-Version: 1.0 X-IsSubscribed: yes On Thu, 2015-01-08 at 14:18 -0700, Jeff Law wrote: > On 01/08/15 05:23, Oleg Endo wrote: > > Hi, > > > > Currently reg_set_p doesn't handle sequence rtx, which I've identified > > as the root cause of PR 64479. There is another alternative fix for the > > PR, but I'd like to get some comments regarding letting reg_set_p also > > handle sequence rtx: > > > > Index: gcc/rtlanal.c > > =================================================================== > > --- gcc/rtlanal.c (revision 218544) > > +++ gcc/rtlanal.c (working copy) > > @@ -875,17 +875,24 @@ > > { > > /* We can be passed an insn or part of one. If we are passed an insn, > > check if a side-effect of the insn clobbers REG. */ > > - if (INSN_P (insn) > > - && (FIND_REG_INC_NOTE (insn, reg) > > - || (CALL_P (insn) > > - && ((REG_P (reg) > > - && REGNO (reg) < FIRST_PSEUDO_REGISTER > > - && overlaps_hard_reg_set_p (regs_invalidated_by_call, > > - GET_MODE (reg), REGNO (reg))) > > - || MEM_P (reg) > > - || find_reg_fusage (insn, CLOBBER, reg))))) > > - return 1; > > + if (INSN_P (insn) && FIND_REG_INC_NOTE (insn, reg)) > > + return true; > > > > + /* After delay slot handling, call and branch insns might be in a > > + sequence. Check all the elements there. */ > > + if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == SEQUENCE) > > + for (int i = 0; i < XVECLEN (PATTERN (insn), 0); ++i) > > + if (reg_set_p (reg, XVECEXP (PATTERN (insn), 0, i))) > > + return true; > > + > > + if (CALL_P (insn) > > + && ((REG_P (reg) && REGNO (reg) < FIRST_PSEUDO_REGISTER > > + && overlaps_hard_reg_set_p (regs_invalidated_by_call, > > + GET_MODE (reg), REGNO (reg))) > > + || MEM_P (reg) > > + || find_reg_fusage (insn, CLOBBER, reg))) > > + return true; > > + > > return set_of (reg, insn) != NULL_RTX; > > } > > > > > > Would that be OK to do if it passes testing, or is there something that > > could potentially/obviously blow up? > It looks reasonable to me. > > Any particular reason why the SEQUENCE handling isn't done first, then > the REG_INC and CALL insn handling? I'd probably explicitly return > false if we had a sequence and none of its elements returned true. > There's no need to check anything on the toplevel SEQUENCE to the best > of my knowledge. No meaningful reason. Attached is an updated patch that applies on 4.8 and trunk. Bootstrapped on trunk i686-pc-linux-gnu. Tested with make -k check RUNTESTFLAGS="--target_board=sh-sim \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" on trunk sh-elf. In the PR it has been reported, that the patch fixes the problems when building a native SH GCC. Although the related SH problem occurs only on 4.8, I'd like to install this on trunk and 4.9, too, to avoid future surprises. OK? Cheers, Oleg gcc/ChangeLog: PR target/64479 * rtlanal.c (set_reg_p): Handle SEQUENCE constructs. Index: gcc/rtlanal.c =================================================================== --- gcc/rtlanal.c (revision 218544) +++ gcc/rtlanal.c (working copy) @@ -873,6 +873,17 @@ int reg_set_p (const_rtx reg, const_rtx insn) { + /* After delay slot handling, call and branch insns might be in a + sequence. Check all the elements there. */ + if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == SEQUENCE) + { + for (int i = 0; i < XVECLEN (PATTERN (insn), 0); ++i) + if (reg_set_p (reg, XVECEXP (PATTERN (insn), 0, i))) + return true; + + return false; + } + /* We can be passed an insn or part of one. If we are passed an insn, check if a side-effect of the insn clobbers REG. */ if (INSN_P (insn) @@ -884,7 +895,7 @@ GET_MODE (reg), REGNO (reg))) || MEM_P (reg) || find_reg_fusage (insn, CLOBBER, reg))))) - return 1; + return true; return set_of (reg, insn) != NULL_RTX; }