From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26631 invoked by alias); 25 Nov 2014 09:25:12 -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 26620 invoked by uid 89); 25 Nov 2014 09:25:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Tue, 25 Nov 2014 09:25:10 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAP9P40j013879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 04:25:04 -0500 Received: from pike.twiddle.home (vpn1-5-182.ams2.redhat.com [10.36.5.182]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAP9P03Z002152; Tue, 25 Nov 2014 04:25:02 -0500 Message-ID: <54744AEA.9010706@redhat.com> Date: Tue, 25 Nov 2014 09:37:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Zhenqiang Chen CC: Marcus Shawcroft , gcc-patches@gcc.gnu.org Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015) References: <000101d007a5$0d120f30$27362d90$@arm.com> <5472F2EA.9000702@redhat.com> <000001d0088b$a4590c40$ed0b24c0$@arm.com> In-Reply-To: <000001d0088b$a4590c40$ed0b24c0$@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg03103.txt.bz2 On 11/25/2014 09:41 AM, Zhenqiang Chen wrote: > I want to confirm with you two things before I rework it. > (1) expand_insn needs an optab_handler as input. Do I need to define a ccmp_optab with different mode support in optabs.def? No, look again: expand_insn needs an enum insn_code as input. Since this is the backend, you can use any icode name you like, which means that you can use CODE_FOR_ccmp_and etc directly. > (2) To make sure later operands not clobber CC, all operands are expanded before ccmp-first in current implementation. If taking tree/gimple as input, what's your preferred logic to guarantee CC not clobbered? Hmm. Perhaps the target hook will need to output two sequences, each of which will be concatenated while looping around the calls to gen_ccmp_next. The first sequence will be operand preparation and the second sequence will be ccmp generation. Something like bool aarch64_gen_ccmp_start(rtx *prep_seq, rtx *gen_seq, int cmp_code, int bit_code, tree op0, tree op1) { bool success; start_sequence (); // Widen and expand operands *prep_seq = get_insns (); end_sequence (); start_sequence (); // Generate the first compare *gen_seq = get_insns (); end_sequence (); return success; } bool aarch64_gen_ccmp_next(rtx *prep_seq, rtx *gen_seq, rtx prev, int cmp_code, int bit_code, tree op0, tree op1) { bool success; push_to_sequence (*prep_seq); // Widen and expand operands *prep_seq = get_insns (); end_sequence (); push_to_sequence (*gen_seq); // Generate the next ccmp *gen_seq = get_insns (); end_sequence (); return success; } If there are ever any failures, the middle-end can simply discard the sequences. If everything succeeds, it simply calls emit_insn on both sequences. r~