From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 5603E385141E; Wed, 9 Sep 2020 13:48:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5603E385141E 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 089DldOY015016; Wed, 9 Sep 2020 08:47:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 089Dldaf015015; Wed, 9 Sep 2020 08:47:39 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 9 Sep 2020 08:47:39 -0500 From: Segher Boessenkool To: Richard Biener Cc: luoxhu , GCC Patches , David Edelsohn , Bill Schmidt , linkw@gcc.gnu.org Subject: Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251] Message-ID: <20200909134739.GX28786@gate.crashing.org> References: <20200904102357.GF28786@gate.crashing.org> <98b124ee-b32d-71f7-a662-e0ce2520de6a@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 13:48:42 -0000 Hi! On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote: > Hmm, yeah - I guess that's what should be addressed first then. > I'm quite sure that in case 'v' is not on the stack but in memory like > in my case a SImode store is better than what we get from > vec_insert - in fact vec_insert will likely introduce a RMW cycle > which is prone to inserting store-data-races? The other way around -- if it is in memory, and was stored as vector recently, then reading back something shorter from it is prone to SHL/LHS problems. There is nothing special about the stack here, except of course it is more likely to have been stored recently if on the stack. So it depends how often it has been stored recently which option is best. On newer CPUs, although they can avoid SHL/LHS flushes more often, the penalty is relatively bigger, so memory does not often win. I.e.: it needs to be measured. Intuition is often wrong here. Segher