From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52735 invoked by alias); 30 Mar 2017 13:10:11 -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 52720 invoked by uid 89); 30 Mar 2017 13:10:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*RU:209.85.216.196, Hx-spam-relays-external:209.85.216.196 X-HELO: mail-qt0-f196.google.com Received: from mail-qt0-f196.google.com (HELO mail-qt0-f196.google.com) (209.85.216.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Mar 2017 13:10:09 +0000 Received: by mail-qt0-f196.google.com with SMTP id x35so6083570qtc.1 for ; Thu, 30 Mar 2017 06:10:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZQD7zl/dpyYcXSWcsGm/VahkPkaqyk3T8IkWXW3114c=; b=mx39XKGm5PLrlvbTF2RIVEjtmDsm/ydf7YThQHDPz6vM2EDSwLotQpOZ5TvMlzczk3 AJIjK7swnecdJhrC3DLZd7dJtcQMUou/2nLZQWV1K/9tRAg2Tc1ecNe+khML0hyd1fYk 9z+sxw8kGaLO+IGxyT7xrCzwi5JSKaiWYe8UusKM+gT71T9RjjlV400LDzZYgGn3MJMm hgxKdmc8vHxwcR6ICkU7ZD9LH1GGfgxWwSc+XExlhkXLzDeG3mTmVcgoKydu4Jjbrf0/ YUSc7U/SfbvsWGc4QCNoF8uExinCxcEYNg6aAAAIJjITYhW1sR/Q57prx8vTxeBYRBoS dURA== X-Gm-Message-State: AFeK/H2ih2eePJKSQdNBhfniabPIhcGBFDQXpkJDogKpW5rm0zsJJ6zn34bFc/IrGBr5cA== X-Received: by 10.200.55.57 with SMTP id o54mr6733330qtb.78.1490879409159; Thu, 30 Mar 2017 06:10:09 -0700 (PDT) Received: from titus (95-25-92-208.broadband.corbina.ru. [95.25.92.208]) by smtp.gmail.com with ESMTPSA id a21sm1356871qkj.54.2017.03.30.06.10.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:10:08 -0700 (PDT) Date: Thu, 30 Mar 2017 13:18:00 -0000 From: Kirill Yukhin To: Jakub Jelinek Cc: Uros Bizjak , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix various avx512 extraction issues (PR target/80206) Message-ID: <20170330130954.GA20466@titus> References: <20170329223620.GI17461@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170329223620.GI17461@tucnak> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg01521.txt.bz2 Hi Jakub, On 30 Mar 00:36, Jakub Jelinek wrote: > Hi! > > As the testcase shows, we ICE with -mavx512f -ffloat-store, because > at -O0 during expansion the destination is MEM, and the corresponding dup > operand is some pseudo. There are *_mask patterns that have just > register_operand / =v for the desination and vector_move_operand / 0C > for the corresponding dup operand (but this doesn't apply when the > destination is MEM), and then *_maskm patterns, that have > memory_operand / =m and corresponding dup operand memory_operand / 0, > but also requires rtx_equal_p between them in the condition, so that > doesn't match either. > The expanders have weirdo: > if (MEM_P (operands[0]) && GET_CODE (operands[3]) == CONST_VECTOR) > operands[0] = force_reg (mode, operands[0]); > which can't really ever work, because the expander's caller expects > the output to be stored in the original operands[0], but that is not > where it stores it. Furthermore, force_reg makes no sense for the > output operand. > > The following patch should fix that, bootstrapped/regtested on x86_64-linux > and i686-linux, ok for trunk? Patch is OK for trunk. -- Thanks, K