From patchwork Thu Mar 17 12:02:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Enkovich X-Patchwork-Id: 599006 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 3qQn6x2V4Kz9s9j for ; Thu, 17 Mar 2016 23:03:04 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=clYWq0Et; 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:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=vAbdB8P0vptjyu3Is9IPifuoK/b0d+KID523GcKwznMCNFbzNTu/o 2Me2ov5faHeWxYj0YRJV/zArSDQoO3CXIy4vngHZ8lIi67WoEFNdaV4AY3pzX6bh gXdYcyc2fGE+VKO9+O9mkIQxHl4AWoBnpCDOhSgkAqp/WmsT+N5B9Y= 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:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=cBTjrh1q0KJPKx9yqIWBysfsK+Y=; b=clYWq0EtYqz3n48usjzI 38nMc19GMieUsxYgOPTymW+GHze0+6SNevgliPn+S2iVckyuaQnEhAQ1hheJQQCs ipLM7LIgytgcb3omqxB717uY9FShZlOZFRpTMhmtsCFDg8MI481U/dtYFlFx1Qcy 0NmvIs6v4w8WZfPkXrklC24= Received: (qmail 9981 invoked by alias); 17 Mar 2016 12:02:57 -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 9969 invoked by uid 89); 17 Mar 2016 12:02:56 -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=quarter, hooks, enkovich.gnu@gmail.com, enkovichgnugmailcom X-HELO: mail-qg0-f53.google.com Received: from mail-qg0-f53.google.com (HELO mail-qg0-f53.google.com) (209.85.192.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 17 Mar 2016 12:02:54 +0000 Received: by mail-qg0-f53.google.com with SMTP id a36so37739579qge.0 for ; Thu, 17 Mar 2016 05:02:54 -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:subject:message-id:mime-version :content-disposition:user-agent; bh=27pgecPH+CstUUAR8h9NLB/rSzCHk75Gvp1Wo7ABzPQ=; b=bKYjeyS45tSQmypXSbg9PVkKZ4TshSR+X8Bxxu1oCwWBfG51JEyAH4Teyg80EPv3kQ YMM4Vb8XSNIV3aV2hL8+YUWPj374ZwWf/CSPFS56oLA8i2/Yb1vFIe9C6W50ktZI0fQc BDmImtaWkkrFUEeNkAKewO9kxg6bSDsmKyiTpJ+qPAMC3QvcoItDtCEe+l0OIl136Mga VKcxWg+eFcdxYn7AW9OAHPQIdmbgnchSAwv7d6+40MnRTFsi81BoMRG/Sq1DvMlUC/aM vq6k+RPGbWH/W4HgPWBbg+KDzpGopYBK2xc7wsAQogOIMyBqVx8PAjbVX0rqGyr3DVRY aAjw== X-Gm-Message-State: AD7BkJIxMdz29vA0HcmtO1tvJPfxm983EggKd4XzChfC+QYthdNwOh0lqTuixfSrTG4byg== X-Received: by 10.140.234.11 with SMTP id f11mr14465577qhc.51.1458216172569; Thu, 17 Mar 2016 05:02:52 -0700 (PDT) Received: from msticlxl57.ims.intel.com (irdmzpr01-ext.ir.intel.com. [192.198.151.36]) by smtp.gmail.com with ESMTPSA id f4sm3651489qkh.23.2016.03.17.05.02.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Mar 2016 05:02:52 -0700 (PDT) Date: Thu, 17 Mar 2016 15:02:02 +0300 From: Ilya Enkovich To: gcc-patches@gcc.gnu.org Subject: [PATCH, PR tree-optimization/70252] Fix boolean vectors conversion Message-ID: <20160317120202.GB2050@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes Hi, Current widening and narrowing vectorization functions may work incorrectly for scalar masks because we may have different boolean vector types having the same mode. E.g. vec(4) and vec(8) both have QImode. That means if we need to convert vec(4) into vec(16) we may actually find QImode->HImode conversion optab and try to use it which is incorrect because this optab entry is used for vec(8) to vec(16) conversion. I suppose the best fix for GCC 6 is to just catch and disable such conversion by checking number of vetor elements. It doesn't disable any vectorization because we don't have any conversion patterns for vec(4) anyway. It's not clear what to do for GCC 7 though to enable such conversions. It looks like for AVX-512 we have three boolean vectors sharing the same QImode: vec(2), vec(4) and vec(8). It means we can't use optabs to check operations on these vectors even using conversion optabs instead of direct ones. Can we use half/quarter byte modes for such masks or something like that? Another option is to handle their conversion separately with no optabs usage at all (target hooks?). The patch was bootstrapped and regtested on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Ilya --- gcc/ 2016-03-17 Ilya Enkovich PR tree-optimization/70252 * tree-vect-stmts.c (supportable_widening_operation): Check resulting boolean vector has a proper number of elements. (supportable_narrowing_operation): Likewise. gcc/testsuite/ 2016-03-17 Ilya Enkovich PR tree-optimization/70252 * gcc.dg/pr70252.c: New test. diff --git a/gcc/testsuite/gcc.dg/pr70252.c b/gcc/testsuite/gcc.dg/pr70252.c new file mode 100644 index 0000000..209e691 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr70252.c @@ -0,0 +1,16 @@ +/* { dg-do compile } */ +/* { dg-options "-O3" } */ +/* { dg-additional-options "-march=skylake-avx512" { target { i?86-*-* x86_64-*-* } } } */ + +extern unsigned char a [150]; +extern unsigned char b [150]; +extern unsigned char c [150]; +extern unsigned char d [150]; +extern unsigned char e [150]; + +void foo () { + for (int i = 92; i <= 141; i += 2) { + int tmp = (d [i] && b [i]) <= (a [i] > c [i]); + e [i] = tmp >> b [i]; + } +} diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index 06b1ab7..d12c062 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -8940,7 +8940,12 @@ supportable_widening_operation (enum tree_code code, gimple *stmt, if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype) && insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype)) - return true; + /* For scalar masks we may have different boolean + vector types having the same QImode. Thus we + add additional check for elements number. */ + return (!VECTOR_BOOLEAN_TYPE_P (vectype) + || (TYPE_VECTOR_SUBPARTS (vectype) / 2 + == TYPE_VECTOR_SUBPARTS (wide_vectype))); /* Check if it's a multi-step conversion that can be done using intermediate types. */ @@ -8991,7 +8996,9 @@ supportable_widening_operation (enum tree_code code, gimple *stmt, if (insn_data[icode1].operand[0].mode == TYPE_MODE (wide_vectype) && insn_data[icode2].operand[0].mode == TYPE_MODE (wide_vectype)) - return true; + return (!VECTOR_BOOLEAN_TYPE_P (vectype) + || (TYPE_VECTOR_SUBPARTS (intermediate_type) / 2 + == TYPE_VECTOR_SUBPARTS (wide_vectype))); prev_type = intermediate_type; prev_mode = intermediate_mode; @@ -9075,7 +9082,12 @@ supportable_narrowing_operation (enum tree_code code, *code1 = c1; if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype)) - return true; + /* For scalar masks we may have different boolean + vector types having the same QImode. Thus we + add additional check for elements number. */ + return (!VECTOR_BOOLEAN_TYPE_P (vectype) + || (TYPE_VECTOR_SUBPARTS (vectype) * 2 + == TYPE_VECTOR_SUBPARTS (narrow_vectype))); /* Check if it's a multi-step conversion that can be done using intermediate types. */ @@ -9140,7 +9152,9 @@ supportable_narrowing_operation (enum tree_code code, (*multi_step_cvt)++; if (insn_data[icode1].operand[0].mode == TYPE_MODE (narrow_vectype)) - return true; + return (!VECTOR_BOOLEAN_TYPE_P (vectype) + || (TYPE_VECTOR_SUBPARTS (intermediate_type) * 2 + == TYPE_VECTOR_SUBPARTS (narrow_vectype))); prev_mode = intermediate_mode; prev_type = intermediate_type;