From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3841 invoked by alias); 6 Sep 2017 17:21:52 -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 3831 invoked by uid 89); 6 Sep 2017 17:21:52 -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,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Sep 2017 17:21:47 +0000 Received: by mail-wr0-f182.google.com with SMTP id k20so6259529wre.4 for ; Wed, 06 Sep 2017 10:21:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=1I4253ATCpxjLI97wayorExbLl5UWJRBF/hW7X0+tmU=; b=VXzJveNTIgCq7gIHDIw+m4hYt5B2j5/wESpb2P0oqVO6BCelgazCaK9kVth7J8jsGN iu8gQ+72Qvgy1CPvRO+cDPn3bmReYbwNVtJYRYOWdaCyEZpv5s8zK20dbh0FRd4iTuMl m9VggU5k9Y80BDsTHjs+9TBKGiBJEQkXkidwBTU4E13lK6shcUNc2NzG7AvQQGSUyE5k DnPj/+0grnT9/t2JO6iGDtwMC10t8WS3myABbTDEQyJXGRXGI48Oe0S9lZnM2gezedz1 r7sMolVxii3eevumhPet3xqHe5G8jAS+pWt32D+Ir9DhRcvdNTg0vtRnoq9PJL4BlCJi piYg== X-Gm-Message-State: AHPjjUitxlI4j914Yumvo6DGj7o3CB3vL8ByPxNkCTjZGPnWPDZX+deq pJO0C1HmzN7GOpky X-Google-Smtp-Source: ADKCNb6czXrdBsL6q00s3sHqz3hjEosiDUzSU7yR+0rhsrDY6UThU9qPPwF1RjI6pkPvixbDM8EK9w== X-Received: by 10.223.130.182 with SMTP id 51mr2055557wrc.325.1504718505038; Wed, 06 Sep 2017 10:21:45 -0700 (PDT) Received: from localhost ([217.140.96.141]) by smtp.gmail.com with ESMTPSA id u15sm313274wrb.76.2017.09.06.10.21.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 06 Sep 2017 10:21:44 -0700 (PDT) From: Richard Sandiford To: Michael Collison Mail-Followup-To: Michael Collison ,Richard Biener , Richard Kenner , GCC Patches , nd , Andrew Pinski , richard.sandiford@linaro.org Cc: Richard Biener , Richard Kenner , GCC Patches , nd , Andrew Pinski Subject: Re: [PATCH] [Aarch64] Optimize subtract in shift counts References: <20170807210159.86DD633CA8@vlsi1.gnat.com> <20170808015616.1386833CA8@vlsi1.gnat.com> <20170808121311.5B7D033CAD@vlsi1.gnat.com> <20170808195158.352B333ED7@vlsi1.gnat.com> <20170808200402.3B4BE33EE9@vlsi1.gnat.com> <20170808202024.8AC9533F0E@vlsi1.gnat.com> <87valgddb2.fsf@linaro.org> <87r2w4cb6w.fsf@linaro.org> <87mv6sc98y.fsf@linaro.org> <87bmmot8wu.fsf@linaro.org> <8760cvu5to.fsf@linaro.org> Date: Wed, 06 Sep 2017 17:21:00 -0000 In-Reply-To: <8760cvu5to.fsf@linaro.org> (Richard Sandiford's message of "Wed, 06 Sep 2017 17:53:23 +0100") Message-ID: <87h8wfspy2.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-09/txt/msg00399.txt.bz2 Richard Sandiford writes: > Richard Sandiford writes: >> Michael Collison writes: >>> Richard, >>> >>> The problem with this approach for Aarch64 is that >>> TARGET_SHIFT_TRUNCATION_MASK is based on SHIFT_COUNT_TRUNCATED which is >>> normally 0 as it based on the TARGET_SIMD flag. >> >> Maybe I'm wrong, but that seems like a missed optimisation in itself. Sorry to follow up on myself yet again, but I'd forgotten this was because we allow the SIMD unit to do scalar shifts. So I guess we have no choice, even though it seems unfortunate. > +(define_insn_and_split "*aarch64_reg__minus3" > + [(set (match_operand:GPI 0 "register_operand" "=&r") > + (ASHIFT:GPI > + (match_operand:GPI 1 "register_operand" "r") > + (minus:QI (match_operand 2 "const_int_operand" "n") > + (match_operand:QI 3 "register_operand" "r"))))] > + "INTVAL (operands[2]) == GET_MODE_BITSIZE (mode)" > + "#" > + "&& true" > + [(const_int 0)] > + { > + /* Handle cases where operand 3 is a plain QI register, or > + a subreg with either a SImode or DImode register. */ > + > + rtx subreg_tmp = (REG_P (operands[3]) > + ? gen_lowpart_SUBREG (SImode, operands[3]) > + : SUBREG_REG (operands[3])); > + > + if (REG_P (subreg_tmp) && GET_MODE (subreg_tmp) == DImode) > + subreg_tmp = gen_lowpart_SUBREG (SImode, subreg_tmp); I think this all simplifies to: rtx subreg_tmp = gen_lowpart (SImode, operands[3]); (or it would be worth having a comment that explains why not). As well as being shorter, it will properly simplify hard REGs to new hard REGs. > + rtx tmp = (can_create_pseudo_p () ? gen_reg_rtx (SImode) > + : operands[0]); > + > + if (mode == DImode && !can_create_pseudo_p ()) > + tmp = gen_lowpart_SUBREG (SImode, operands[0]); I think this too would be simpler with gen_lowpart: rtx tmp = (can_create_pseudo_p () ? gen_reg_rtx (SImode) : gen_lowpart (SImode, operands[0])); > + > + emit_insn (gen_negsi2 (tmp, subreg_tmp)); > + > + rtx and_op = gen_rtx_AND (SImode, tmp, > + GEN_INT (GET_MODE_BITSIZE (mode) - 1)); > + > + rtx subreg_tmp2 = gen_lowpart_SUBREG (QImode, and_op); > + > + emit_insn (gen_3 (operands[0], operands[1], subreg_tmp2)); > + DONE; > + } > +) The pattern should probably set the "length" attribute to 8. Looks good to me with those changes FWIW. Thanks, Richard