From patchwork Mon Aug 29 12:09:05 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 112030 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]) by ozlabs.org (Postfix) with SMTP id AB773B6F7F for ; Mon, 29 Aug 2011 22:09:24 +1000 (EST) Received: (qmail 4246 invoked by alias); 29 Aug 2011 12:09:21 -0000 Received: (qmail 4231 invoked by uid 22791); 29 Aug 2011 12:09:19 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-yw0-f47.google.com (HELO mail-yw0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Aug 2011 12:09:06 +0000 Received: by ywa12 with SMTP id 12so4730900ywa.20 for ; Mon, 29 Aug 2011 05:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.54.7 with SMTP id c7mr4689887yba.250.1314619745550; Mon, 29 Aug 2011 05:09:05 -0700 (PDT) Received: by 10.150.57.5 with HTTP; Mon, 29 Aug 2011 05:09:05 -0700 (PDT) In-Reply-To: References: <4E4D224F.1020206@redhat.com> Date: Mon, 29 Aug 2011 14:09:05 +0200 Message-ID: Subject: Re: Vector Comparison patch From: Richard Guenther To: Uros Bizjak Cc: Artem Shinkarov , Richard Henderson , gcc-patches@gcc.gnu.org, "Joseph S. Myers" X-IsSubscribed: yes 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 On Mon, Aug 22, 2011 at 9:50 PM, Uros Bizjak wrote: > On Mon, Aug 22, 2011 at 5:34 PM, Richard Guenther > wrote: > >>> In this case it is simple to analyse that a is a comparison, but you >>> cannot embed the operations of a into VEC_COND_EXPR. >> >> Sure, but if the above is C source the frontend would generate >> res = a != 0 ? v0 : v1; initially.  An optimization pass could still >> track this information and replace VEC_COND_EXPR >> with VEC_COND_EXPR (no existing one would track >> vector contents though). >> >>> Ok, I am testing the patch that removes hooks. Could you push a little >>> bit the backend-patterns business? >> >> Well, I suppose we're waiting for Uros here.  I hadn't much luck with >> fiddling with the mode-iterator stuff myself. > > It is not _that_ trivial change, since we have ix86_expand_fp_vcond > and ix86_expand_int_vcond to merge. ATM, FP version deals with FP > operands and vice versa. We have to merge them somehow and split out > comparison part that handles FP as well as integer operands. > > I also don't know why vcond is not allowed to FAIL... probably > middle-end should be enhanced for a fallback if some comparison isn't > supported by optab. I wonder, if we make vcond being able to FAIL (well, it would fail for invalid input only, like mismatching mode size), if patches along would be enough to make it accept V4SF < V4SF ? V4SI : V4SI with target mode V4SI. The expander code doesn't seem to care about the modes of op1/2 too much. Richard. > Uros. > Index: gcc/config/i386/sse.md =================================================================== --- gcc/config/i386/sse.md (revision 178209) +++ gcc/config/i386/sse.md (working copy) @@ -1406,13 +1406,13 @@ (define_insn "_ucomi" (set_attr "mode" "")]) (define_expand "vcond" - [(set (match_operand:VF 0 "register_operand" "") - (if_then_else:VF + [(set (match_operand 0 "register_operand" "") + (if_then_else (match_operator 3 "" [(match_operand:VF 4 "nonimmediate_operand" "") (match_operand:VF 5 "nonimmediate_operand" "")]) - (match_operand:VF 1 "general_operand" "") - (match_operand:VF 2 "general_operand" "")))] + (match_operand 1 "general_operand" "") + (match_operand 2 "general_operand" "")))] "TARGET_SSE" { bool ok = ix86_expand_fp_vcond (operands);