From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39082 invoked by alias); 11 Apr 2017 15:07:08 -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 36172 invoked by uid 89); 11 Apr 2017 15:07:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 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-ua0-f178.google.com Received: from mail-ua0-f178.google.com (HELO mail-ua0-f178.google.com) (209.85.217.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Apr 2017 15:07:05 +0000 Received: by mail-ua0-f178.google.com with SMTP id q26so39926uaa.0 for ; Tue, 11 Apr 2017 08:07:06 -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=XUReBf532T4tw7jRB7O8SehxBqDeZcbaHF0/dwO174w=; b=borV2V9wFFz1iYsGLU4cIJFoxK+ny65hSqwU9KuusRpdpA+Xy+ecgKjggShUur5+qD uwWFtR04p7mUUquVUELWuzeL5TsZqZKnbGUMg551HjW9tM1txb0xOikU3LmGOoIOvETr u6CzmbOiJAu4QFZz+eZnqq5+SqYmjCCcwfsokp92eR3AgVsrfrDxfuBeNhkZuvBRCM3E sJamiPTovnV7s4jJ7oRz6TcvAU3fuXR1iEFTWEmz6+C1xEApqQ/dn0ikcEzT9jtwAUPa B0PGwypN1MNjIH84odwKO7hBR21PkrJMVo87ZAcDYw7i8TlLcXlCfhy8+tPOTnacV5dW Q7Tw== X-Gm-Message-State: AFeK/H1GFEnp7J8EY2QGJeqecPEQzmr2Gmt2eOjhvDlASeDEB1HsF4Nx3gf3ey+r2wiEJ/bqwJEEDa808v7dRA== X-Received: by 10.159.32.163 with SMTP id 32mr31202710uaa.160.1491923224790; Tue, 11 Apr 2017 08:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.12.129 with HTTP; Tue, 11 Apr 2017 08:07:04 -0700 (PDT) In-Reply-To: References: <0296a54f-cb8d-d9b8-380a-9cc553dbb6da@linux.vnet.ibm.com> From: "Bin.Cheng" Date: Tue, 11 Apr 2017 15:07:00 -0000 Message-ID: Subject: Re: [RFC] S/390: Alignment peeling prolog generation To: Robin Dapp Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00532.txt.bz2 On Tue, Apr 11, 2017 at 4:03 PM, Robin Dapp wrote: > Hi Bin, > >> Seems Richi added code like below comparing costs between aligned and >> unsigned loads, and only peeling if it's beneficial: >> >> /* In case there are only loads with different unknown misalignments, use >> peeling only if it may help to align other accesses in the loop or >> if it may help improving load bandwith when we'd end up using >> unaligned loads. */ >> tree dr0_vt = STMT_VINFO_VECTYPE (vinfo_for_stmt (DR_STMT (dr0))); >> if (!first_store >> && !STMT_VINFO_SAME_ALIGN_REFS ( >> vinfo_for_stmt (DR_STMT (dr0))).length () >> && (vect_supportable_dr_alignment (dr0, false) >> != dr_unaligned_supported >> || (builtin_vectorization_cost (vector_load, dr0_vt, 0) >> == builtin_vectorization_cost (unaligned_load, dr0_vt, -1)))) >> do_peeling = false; > > yes this is the "special case" I was referring to. This successfully > avoids peeling when there is no store (after we had set vectorization > costs). My patch tries to check the costs for all references. I am not sure if all references need to be checked, on AArch64, aligned/unaligned costs are set globally, so only need to make one check here. Thanks, bin > > Regards > Robin >