From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id 14C5B385DC33;
 Mon, 14 Sep 2020 21:07:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 14C5B385DC33
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=fail smtp.mailfrom=segher@kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 08EL6e38014898;
 Mon, 14 Sep 2020 16:06:40 -0500
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 08EL6dSJ014897;
 Mon, 14 Sep 2020 16:06:39 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Mon, 14 Sep 2020 16:06:39 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org>,
 luoxhu <luoxhu@linux.ibm.com>, Richard Biener <richard.guenther@gmail.com>,
 Bill Schmidt <wschmidt@linux.ibm.com>,
 David Edelsohn <dje.gcc@gmail.com>, linkw@gcc.gnu.org,
 richard.sandiford@arm.com
Subject: Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of
 gimple [PR79251]
Message-ID: <20200914210639.GC28786@gate.crashing.org>
References: <CAFiYyc17PyP++95TWjyOJQd52+EbSN+95f7R+ZZS1T_aNfxy_w@mail.gmail.com>
 <98b124ee-b32d-71f7-a662-e0ce2520de6a@linux.ibm.com>
 <CAFiYyc3hZyxo4_v_SGZ-WRGuDR9FZBFVBfQ4T4X7in0KXRSKgQ@mail.gmail.com>
 <20200909134739.GX28786@gate.crashing.org>
 <CAFiYyc1A+uyhLudiTz7MVLAZ+oBCtyQpvOLcDA9jsnqGCFvgKg@mail.gmail.com>
 <20200909160057.GZ28786@gate.crashing.org>
 <CAFiYyc3CF40xF-aSgcd8YjBRLFb18enMLDbguE0iKPgvMfD6Kw@mail.gmail.com>
 <572b36a7-2d52-2f46-05bd-140e16794a61@linux.ibm.com>
 <CAFiYyc3JTfmraYpVb6Q7gXao8kUbDb3ieKzJf86M8cf1cSgtOQ@mail.gmail.com>
 <mptlfhcab3b.fsf@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <mptlfhcab3b.fsf@arm.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, KAM_MANYTO, TXREP, T_SPF_HELO_PERMERROR,
 T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 21:07:45 -0000

On Mon, Sep 14, 2020 at 11:47:52AM +0100, Richard Sandiford wrote:
> Would it be worth changing the optab so that the input and output are
> separate?  Having a single operand would be justified if the operation
> was only supposed to touch the selected bytes, but most targets wouldn't
> guarantee that for memory operands, even as things stand.

You have my vote.

> Or maybe the idea was to force the RA's hand by making the input and
> output tied even before RA, with separate moves where necessary.
> But I'm not sure why vec_set is so special that it requires this
> treatment and other optabs don't.

Yeah.  The register allocator is normally very good in using the same
reg in both places, if that is useful.  And it also handles the case
where your machine insns require the two to be the same pretty well.
Not restricting this stuff before RA should be a win.


Segher