From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7914 invoked by alias); 16 Feb 2018 04:42:13 -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 7905 invoked by uid 89); 16 Feb 2018 04:42:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=among X-HELO: homiemail-a80.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a80.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Feb 2018 04:42:11 +0000 Received: from homiemail-a80.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a80.g.dreamhost.com (Postfix) with ESMTP id EC218E000838; Thu, 15 Feb 2018 20:42:09 -0800 (PST) Received: from linaro-laptop.intra.reserved-bit.com (unknown [202.189.238.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by homiemail-a80.g.dreamhost.com (Postfix) with ESMTPSA id A462CE000834; Thu, 15 Feb 2018 20:42:08 -0800 (PST) Reply-To: siddhesh@sourceware.org Subject: Re: [PING][PATCH v3] Disable reg offset in quad-word store for Falkor To: Wilco Dijkstra Cc: GCC Patches , nd References: From: Siddhesh Poyarekar Message-ID: <92252605-6083-ea7c-1026-2c1024839fe8@sourceware.org> Date: Fri, 16 Feb 2018 04:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-02/txt/msg00948.txt.bz2 On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote: > So it seems to me using existing cost mechanisms is always preferable, even if you > currently can't differentiate between loads and stores. Luis is working on address cost adjustments among other things, so I guess the path of least resistance for gcc8 is to have those adjustments go in and then figure out how much improvement this patch (or separating loads and stores) would get on top of that. Would that be acceptable? Siddhesh