From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80965 invoked by alias); 22 Sep 2017 21:11:46 -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 80241 invoked by uid 89); 22 Sep 2017 21:11:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Sep 2017 21:11:43 +0000 Received: by mail-oi0-f44.google.com with SMTP id b1so240032oih.4 for ; Fri, 22 Sep 2017 14:11:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpSpgI32J3734kNHHNFWlCk07hnhUd0pog/fAtE2yxU=; b=h9cUFC1YvrOXe8Ltgqx89zsJ30qtPF90zs799HSuLPCq+Ay1pj6s1cdh1ahdxOEJPk 1bViFlIyezzc4RyluNNn/h89ro6yVl1APVKSMaxQnAJLrfXXOJk3V2+3wWu/GyOJ1CgI JPHbSVUwSsMuMPlj75ukGtsADHg0JF6MsdUcaOFiX7XMXxL7Ztl6zoMPy1WZSiHgFTRz 0aCxQkbi5zOeTkCoFT1fjPH44sn0whR/NnxCef+GHY/D1n1vLBZULg2otBUOPrXkIX8J ZSb1x553XL6zse3mgoCtYWRr3MQl6TgjdXGfQbCu6j5HvnBwvbYGh/ojoNBZ2X+d1EK5 qmbQ== X-Gm-Message-State: AHPjjUh4ShL9VYn/OhCBAHlUUEhO/2UqZk2DsKwSTggZrd5ZLItGgUTO lwP72sTJtqixM+OFCrNQa+UzR+YQ1Hf0i8lfvys= X-Google-Smtp-Source: AOwi7QAsPbZdabHW5M18D3O6VR79Y13pt5f/HcOrhWSU1icu57UqVIynBGQ5g2W4lgFUu5qXff6StKpwQ4cwNyZmUeI= X-Received: by 10.202.12.66 with SMTP id i2mr607738oiy.314.1506114701910; Fri, 22 Sep 2017 14:11:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.27.244 with HTTP; Fri, 22 Sep 2017 14:11:41 -0700 (PDT) In-Reply-To: References: <1506095357-3334-1-git-send-email-jim.wilson@linaro.org> From: Andrew Pinski Date: Fri, 22 Sep 2017 21:11:00 -0000 Message-ID: Subject: Re: [PATCH, AArch64] Disable reg offset in quad-word store for Falkor. To: Jim Wilson Cc: "gcc-patches@gcc.gnu.org" , Jim Wilson Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg01574.txt.bz2 On Fri, Sep 22, 2017 at 11:39 AM, Jim Wilson wrote: > On Fri, Sep 22, 2017 at 10:58 AM, Andrew Pinski wrote: >> Two overall comments: >> * What about splitting register_offset into two different elements, >> one for non 128bit modes and one for 128bit (and more; OI, etc.) modes >> so you get better address generation right away for the simd load >> cases rather than having LRA/reload having to reload the address into >> a register. > > I'm not sure if changing register_offset cost would make a difference, > since costs are usually used during optimization, not during address > generation. This is something that I didn't think to try though. I > can try taking a look at this. It does taken into account when fwprop is propagating the addition into the MEM (the tree level is always a_1 = POINTER_PLUS_EXPR; MEM_REF(a_1)). IV-OPTS will produce much better code if the address_cost is correct. It looks like no other pass (combine, etc.) would take that into account except for postreload CSE but maybe they should. > > I did try writing a patch to modify predicates to disallow reg offset > for 128bit modes, and that got complicated, as I had to split apart a > number of patterns in the aarch64-simd.md file that accept both VD and > VQ modes. I ended up with a patch 3-4 times as big as the one I > submitted, without any additional performance improvement, so it > wasn't worth the trouble. > >> * Maybe adding a testcase to the testsuite to show this change. > > Yes, I can add a testcase. > >> One extra comment: >> * should we change the generic tuning to avoid reg+reg for 128bit modes? > > Are there other targets with a similar problem? I only know that it > is a problem for Falkor. It might be a loss for some targets as it is > replacing one instruction with two. Well that is why I was suggesting the address cost model change. Because the cost model change actually might provide better code in the first place and still allow for reasonable generic code to be produced. Thanks, Andrew > > Jim