From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8628 invoked by alias); 22 Sep 2014 16:29:26 -0000 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 Received: (qmail 8616 invoked by uid 89); 22 Sep 2014 16:29:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 22 Sep 2014 16:29:24 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8MGTI2R013849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Sep 2014 12:29:19 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8MGTIke021782; Mon, 22 Sep 2014 12:29:18 -0400 Message-ID: <54204E5E.3090406@redhat.com> Date: Mon, 22 Sep 2014 16:29:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" , richard.sandiford@arm.com Subject: Re: [PATCH 4/5] Generalise invalid_mode_change_p References: <87ppetnsxd.fsf@e105548-lin.cambridge.arm.com> <878ulhns3d.fsf@e105548-lin.cambridge.arm.com> <541C6DA0.8040405@redhat.com> <87lhpcm7lr.fsf@e105548-lin.cambridge.arm.com> In-Reply-To: <87lhpcm7lr.fsf@e105548-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg01851.txt.bz2 On 09/22/14 01:34, Richard Sandiford wrote: > Jeff Law writes: >> On 09/18/14 04:25, Richard Sandiford wrote: >>> This is the main patch for the bug. We should treat a register as invalid >>> for a mode change if simplify_subreg_regno cannot provide a new register >>> number for the result. We should treat a class as invalid for a mode change >>> if all registers in the class are invalid. This is an extension of the old >>> CANNOT_CHANGE_MODE_CLASS-based check (simplify_subreg_regno checks C_C_C_M). >>> >>> I forgot to say that the patch is a prerequisite to removing aarch64's >>> C_C_C_M. There are other prerequisites too, but removing C_C_C_M without >>> this patch caused regressions in the existing testsuite, which is why no >>> new tests are needed. >>> >>> >>> gcc/ >>> * hard-reg-set.h: Include hash-table.h. >>> (target_hard_regs): Add a finalize method and a x_simplifiable_subregs >>> field. >>> * target-globals.c (target_globals::~target_globals): Handle >>> hard_regs->finalize. >>> * rtl.h (subreg_shape): New structure. >>> (shape_of_subreg): New function. >>> (simplifiable_subregs): Declare. >>> * reginfo.c (simplifiable_subreg): New structure. >>> (simplifiable_subregs_hasher): Likewise. >>> (simplifiable_subregs): New function. >>> (invalid_mode_changes): Delete. >>> (alid_mode_changes, valid_mode_changes_obstack): New variables. >>> (record_subregs_of_mode): Remove subregs_of_mode parameter. >>> Record valid mode changes in valid_mode_changes. >>> (find_subregs_of_mode): Remove subregs_of_mode parameter. >>> Update calls to record_subregs_of_mode. >>> (init_subregs_of_mode): Remove invalid_mode_changes and bitmap >>> handling. Initialize new variables. Update call to >>> find_subregs_of_mode. >>> (invalid_mode_change_p): Check new variables instead of >>> invalid_mode_changes. >>> (finish_subregs_of_mode): Finalize new variables instead of >>> invalid_mode_changes. >>> (target_hard_regs::finalize): New function. >>> * ira-costs.c (print_allocno_costs): Call invalid_mode_change_p >>> even when CLASS_CANNOT_CHANGE_MODE is undefined. >>> >>> Index: gcc/rtl.h >>> =================================================================== >>> --- gcc/rtl.h 2014-09-15 11:55:40.459855161 +0100 >>> +++ gcc/rtl.h 2014-09-15 12:26:21.249077760 +0100 >>> +/* Return the shape of a SUBREG rtx. */ >>> + >>> +static inline subreg_shape >>> +shape_of_subreg (const_rtx x) >>> +{ >>> + return subreg_shape (GET_MODE (SUBREG_REG (x)), >>> + SUBREG_BYTE (x), GET_MODE (x)); >>> +} >>> + >> Is there some reason you don't have a constructor that accepts a >> const_rtx? > > I was worried that by allowing implicit const_rtx->subreg_shape > conversions, it would be less obvious that the rtx has to have > code SUBREG. I.e. a checked conversion would be hidden in the > constructor rather than being explicit. > > If with David's new rtx hierarchy we end up with an rtx_subreg > subclass then I agree we should have a constructor that takes > one of those. Makes sense. I'm not sure if I was explicit, but the patch is fine, that was more a curiosity on my part than anything. jeff