From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19510 invoked by alias); 30 Aug 2011 09:12:58 -0000 Received: (qmail 19486 invoked by uid 22791); 30 Aug 2011 09:12:56 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_ZJ X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 09:12:34 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 2EDE88EFD4; Tue, 30 Aug 2011 11:12:33 +0200 (CEST) Date: Tue, 30 Aug 2011 09:39:00 -0000 From: Richard Guenther To: Jakub Jelinek Cc: Uros Bizjak , gcc-patches@gcc.gnu.org, uros@gcc.gnu.org, rth@redhat.com, artyom.shinkaroff@gmail.com Subject: Re: [PATCH] Change vcond to vcond In-Reply-To: <20110830090713.GG2687@tyan-ft48-01.lab.bos.redhat.com> Message-ID: References: <20110830090713.GG2687@tyan-ft48-01.lab.bos.redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-1354026085-1314695553=:2130" 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 X-SW-Source: 2011-08/txt/msg02422.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-1354026085-1314695553=:2130 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-length: 1527 On Tue, 30 Aug 2011, Jakub Jelinek wrote: > On Tue, Aug 30, 2011 at 11:02:02AM +0200, Uros Bizjak wrote: > > > Hmm.  But then I'd have to try emit an insn, right?  Currently > > > the vectorizer simply looks for an optab handler ... the > > > operands are not readily available (but their mode is known). > > > So I'd create some fake regs, setup operands and call GEN_FCN > > > on it?  If it succeds I'd have to delete emitted insns, etc. > > > Or I could add a target hook ... > > > > Hm... indeed, too much complication... > > > > I'd say, let's go with modeless operands and a target hook. IMO, this > > is much more flexible than checking optab for supported modes. > > Existing way is appropriate for single mode patterns, but we have > > interdependent modes here, at least on x86. > > > > The hook would have two input arguments, insn mode and compare mode, > > where the hook returns suggested supported compare mode, or no mode, > > if it really can't handle requested modes. > > I think a two mode vcond pattern is in fact much cleaner than > a one mode + modeless pattern which gen* will complain about and > a target hook. Btw, what I meant with lumping together two insns in vcond is that it is really a combination of vcreatecondmask where mode is the comparison and mask mode, a convert-move and a vapplycondmask where the mode is now the mode of the values and the converted mask. But that would of course make it difficult for targets with vector condition codes to support vcond. Richard. --8323584-1354026085-1314695553=:2130--