From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60654 invoked by alias); 28 Jun 2016 14:09:05 -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 60640 invoked by uid 89); 28 Jun 2016 14:09:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=act X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Jun 2016 14:09:01 +0000 Received: by mail-wm0-f42.google.com with SMTP id v199so141583247wmv.0 for ; Tue, 28 Jun 2016 07:09:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IRS5dJfkDYZtO7a6dhHJotxMLL/l/t+tvmW0VoJ+Yy8=; b=Q/qY4NIlduMvXN3lsTs6smAQcsCXN/xptCb7eW3T8p+2bw958Ln0kkLvFgNIjCFv6k j07phsPSAeLp18WWHIhMzVYB0L77YOghjw0gn3jjYA38WKmlfNY6/CcEdNUST4lUosFb c1EIrrJbVGtrRnMdRQOO06lIwwv6A0dDpId4NlIT8mohYJ2hNt7p+E7deNU968cZ+Qv5 rI0Vwv6Zdl9cqJpzXtQjxJv66ad7u8wDlCCPsrlTTDlFFHImhs2+WOAVKnPjOOmh4i34 tmwHpPk3M2dMQJF6EZP0GD/CjAu5BLSWUkQRV0i5wZDvvBb96CUtiOYS1lNgDa9Fz98i qhvg== X-Gm-Message-State: ALyK8tKEjjFMCN3a0/O9Wn72VgE6KvYl6iyGmK8yNCc5jwk3pjZR19/EimzKAnFA8eYuBg== X-Received: by 10.28.4.140 with SMTP id 134mr16595116wme.91.1467122938236; Tue, 28 Jun 2016 07:08:58 -0700 (PDT) Received: from msticlxl57.ims.intel.com (irdmzpr02-ext.ir.intel.com. [192.198.151.37]) by smtp.gmail.com with ESMTPSA id w81sm3527447wmg.20.2016.06.28.07.08.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jun 2016 07:08:57 -0700 (PDT) Date: Tue, 28 Jun 2016 14:16:00 -0000 From: Ilya Enkovich To: Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH, vec-tails 07/10] Support loop epilogue combining Message-ID: <20160628140633.GB11812@msticlxl57.ims.intel.com> References: <20160519194450.GH40563@msticlxl57.ims.intel.com> <18ccae1a-30c3-c23c-e28f-287f9d41eaa0@redhat.com> <20160628122439.GB4143@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160628122439.GB4143@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg01887.txt.bz2 On 28 Jun 15:24, Ilya Enkovich wrote: > On 16 Jun 10:54, Jeff Law wrote: > > > > I don't see anything particularly worrisome here either -- I have a slight > > concern about correctness issues with only masking loads/stores and > > reductions. But I will defer to your judgment on whether or not there's > > other stuff that we need to mask to combine the epilogue with the loop via > > masking. > > We have to mask operations which may cause errors if executed speculatively. > For others we just ignore produced result. So we don't truly mask reductions > but fix-up their results. I assume memory accesses are only ones we have to > truly mask (plus non-const calls which are rejected now). For signalling > arithmetic I assumed we just don't vectorize it. > > Basically we should act similar to if-conversion. I'll check if it has > restrictions I miss. I see if-conversion pass checks non-memory statements using gimple_could_trap_p_1 but I don't see similar checks in the vectorizer. Therefore I add similar check into patch #05. Currently we don't have a way to mask such statements except mask their operands to exclude zeros, NaNs etc. and replace them with whatever we want. This seems inefficient though and most probably wouldn't fold into real masked instruction on RTL. We may handle those cases later if find them important. Thanks, Ilya > > > > > Jeff > > Here is an updated patch version. > > Thanks, > Ilya > --