From patchwork Thu May 11 12:14:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 761040 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wNsVP3KMBz9sDB for ; Thu, 11 May 2017 22:14:36 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="L7MYeT1w"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=cWbl70eqgi7GAOt 1irFCCxBNh6jSw6RGs2kwlXJzp8kEcVx1KE7lEkiNOI/MyWXD1EWP53cNWUuNQI5 iYSr4EvS9tXYIrhBf/MZanATCcjG54NNW4meA5lXZA1nDG9H6tZx030dpet5OeyG h4lIWqQsaSrhAj4LARAqXdaqi5NI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=CzYSHZ1aIXTY+TUtaDcoA Unq3gM=; b=L7MYeT1wvUH/SJFDSMRydu/7/8OXlVDi/mydIxLFBT5V259iY03Xt vGNA8yQCpu8wDWPaf5w2Zlob9LcQuRl/aXfr5tOqCoz7U+8qqrPYIMdXemzagJsj ahyUvyanUR1gMTMy/hsgJipOgKoBCxTHeTqJYm1G2Haw6FMyC1Mcsw= Received: (qmail 97252 invoked by alias); 11 May 2017 12:14:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 97236 invoked by uid 89); 11 May 2017 12:14:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f50.google.com Received: from mail-oi0-f50.google.com (HELO mail-oi0-f50.google.com) (209.85.218.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 May 2017 12:14:22 +0000 Received: by mail-oi0-f50.google.com with SMTP id h4so27389688oib.3 for ; Thu, 11 May 2017 05:14:25 -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=NKlA1XgEdVa7bov4mj1JKA/c8TGQ3vXdc4b6zC8Aun0=; b=KbrcvQNyCPJ1YDdp8kaMgT04nD8VfQZv1Rc/Cy/B8NaddDy6TY9Ih4d5CmR4hM2FXO 18pN02rnzsyzLvLbvtkedg5eoNVCKSkb7HqkZxiuxNbKd+559kfF3Yu6qPQqmRDVeyWi DwnSeY2w9VC0lBDEGC8LqbgaXx5VmjXZ9nUA0H4RA65iUJHtL/70w1/7SXBiCBNnw81w dKLWoygwEsqDRgIuy6kURTANryF1FQanV6/p5/JfAMXEn7avAzkbWLiYrfEbaDTZaw6W 64vQdCuvepawhJwrFzUvv4PxR0dNRypODK2TdqlV2cB/udmhJ1uWoUNvrHGB8Ubm1Uzn Yodw== X-Gm-Message-State: AODbwcAzGMSBhAXCOb1VrKvhFwZbDO0sBwA38uJvT2fLIUF5Zr0xUEof ZwD2lZoEk2e0sOUvXyjns0pCuEj1OA== X-Received: by 10.157.46.234 with SMTP id w97mr4789130ota.78.1494504864095; Thu, 11 May 2017 05:14:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.83 with HTTP; Thu, 11 May 2017 05:14:23 -0700 (PDT) In-Reply-To: References: <0296a54f-cb8d-d9b8-380a-9cc553dbb6da@linux.vnet.ibm.com> <2804E9EF-67D1-4EFD-AF29-65C634EBE24F@gmail.com> <6f1194a0-9e57-0028-faf4-6190beec2009@linux.vnet.ibm.com> <3e575f6d-874a-b260-1fc2-f4db1250c32b@linux.vnet.ibm.com> From: Richard Biener Date: Thu, 11 May 2017 14:14:23 +0200 Message-ID: Subject: Re: [RFC] S/390: Alignment peeling prolog generation To: Robin Dapp Cc: GCC Patches , "Bin.Cheng" X-IsSubscribed: yes On Thu, May 11, 2017 at 1:15 PM, Robin Dapp wrote: > Included the requested changes in the patches (to follow). I removed > the alignment count check now altogether. > >> I'm not sure why you test for unlimited_cost_model here as I said >> elsewhere I'm not sure >> what not cost modeling means for static decisions. The purpose of >> unlimited_cost_model >> is to always vectorize when possible and omit the runtime >> profitability check. So for peeling >> I'd just always use the cost model. Thus please drop this check. > > Without that, I get one additional FAIL gcc.dg/vect/slp-25.c for x86. > It is caused by choosing no peeling (inside costs 0) over peeling for > known alignment with unlimited cost model (inside costs 0 as well). > Costs 0 for no peeling are caused by count == 0 or rather ncopies = vf / > nunits == 4 / 8 == 0 in record_stmt_costs (). Shouldn't always hold > ncopies > 0? Even 0.5 would have worked here to make no peeling more > expensive than 0. That's odd. I can't get to ICE with the testcase (unpatched trunk) Where's that record_stmt_cost call done? You can't simply use vf/nunits for SLP. Richard. > Test suite on s390x is clean. > > Regards > Robin > Index: gcc/tree-vect-stmts.c =================================================================== --- gcc/tree-vect-stmts.c (revision 247882) +++ gcc/tree-vect-stmts.c (working copy) @@ -95,6 +96,7 @@ record_stmt_cost (stmt_vector_for_cost * enum vect_cost_for_stmt kind, stmt_vec_info stmt_info, int misalign, enum vect_cost_model_location where) { + gcc_assert (count > 0); if (body_cost_vec) { tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;