From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33071 invoked by alias); 31 Aug 2019 00:52:00 -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 32986 invoked by uid 89); 31 Aug 2019 00:52:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*RU:209.85.214.196, HX-Spam-Relays-External:209.85.214.196, H*i:sk:WkDFGR0, H*f:sk:WkDFGR0 X-HELO: mail-pl1-f196.google.com Received: from mail-pl1-f196.google.com (HELO mail-pl1-f196.google.com) (209.85.214.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 31 Aug 2019 00:51:58 +0000 Received: by mail-pl1-f196.google.com with SMTP id o3so4054381plb.13 for ; Fri, 30 Aug 2019 17:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=QBHLAgEbTUuWYbk4wr6a0JR5apY43zYhm96VFLLVuUY=; b=K/eZkAWPzLT27vy+MhIFvoLvc/RsAU8zO+g8EZk5Y9NyTWO4QbMOHuFrevNpmXW2q2 YWrhtXKJnc9FfaCbRGuc48VNZowuQCLlm5Rs0hjm161hfltwcCe1ocBwAt2fvanGhACr ZDNmgdjphEaoPIcFscxb9QpoNWlje3GUfaKBvufm++quifAtlmTXgMfYTmh9VTlUoIgp oTGQ8jhHqXflpVxtZK2+bV15oAZ0Bn/6IRwWLXzCaCzSH0AahnJ+EQas1DGvHcecnsma A5JtwYtCY1z8eGpHvnMYsl7sTH8yBKXTKNOO0vVJa2J1biJAqLkJY58DFqaACNDjXiyY SgHQ== Return-Path: Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:4524:1046:c45f:87cb]) by smtp.gmail.com with ESMTPSA id z6sm8879194pgk.18.2019.08.30.17.51.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Aug 2019 17:51:55 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 039E2805B0; Sat, 31 Aug 2019 10:21:51 +0930 (ACST) Date: Sat, 31 Aug 2019 03:01:00 -0000 From: Alan Modra To: Uros Bizjak Cc: Richard Biener , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, i386]: Do not limit the cost of moves to/from XMM register to minimum 8. Message-ID: <20190831005151.GD9227@bubble.grove.modra.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg02120.txt.bz2 On Fri, Aug 30, 2019 at 09:42:06AM +0200, Uros Bizjak wrote: > On Fri, Aug 30, 2019 at 9:22 AM Richard Biener > wrote: > > > > On Thu, Aug 29, 2019 at 9:54 AM Uros Bizjak wrote: > > > > > > On Wed, Aug 28, 2019 at 5:12 PM Uros Bizjak wrote: > > > > > > > > Attached patch improves costing for STV shifts and corrects reject > > > > condition for out of range shift count operands. > > > > > > > > 2019-08-28 Uroš Bizjak > > > > > > > > * config/i386/i386-features.c > > > > (general_scalar_chain::compute_convert_gain): > > > > Correct cost for double-word shifts. > > > > (general_scalar_to_vector_candidate_p): Reject count operands > > > > greater or equal to mode bitsize. > > > > > > > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. > > > > > > > > Committed to mainline SVN. > > > > > > Ouch... I mixed up patches and actually committed the patch that > > > removes maximum from cost of sse<->int moves. > > > > > > I can leave the patch for a day, so we can see the effects of the cost > > > change, and if the patch creates problems, I'll revert it. > > > > Regresses gromacs and namd quite a bit on Haswell, also perl in SPEC 2000. > > I guess we should try understand why rather than reverting immediately > > (I'd leave it in at least another few days to get more testers pick up the > > rev.). > > The correct patch is actually [1] (I have updated the subject): > > 2019-08-28 Uroš Bizjak > > * config/i386/i386.c (ix86_register_move_cost): Do not > limit the cost of moves to/from XMM register to minimum 8. > > There is no technical reason to limit the costs to minimum 8 anymore, > and several targets (e.g skylake) also claim that moves between SSE > and general regs are as cheap as moves between general regs. However, > these values were never benchmarked properly due to the mentioned > limitation and apparently cause some unwanted secondary effects > (lowering the clock). > > I agree with your proposal to leave the change in the tree some more > time. At the end, we could raise the costs for all targets to 8 to > effectively revert to the previous state. > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02009.html Those SPEC regressions sound similar to what I saw when trying to give proper costing to moves between general regs and vsx regs on Power9. rs6000.c:rs6000_ira_change_pseudo_allocno_class is the hack I used to work around bad register allocation decisions due to poor register pressure calculation. -- Alan Modra Australia Development Lab, IBM