From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28266 invoked by alias); 30 Aug 2011 09:20:47 -0000 Received: (qmail 28245 invoked by uid 22791); 30 Aug 2011 09:20:47 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 09:20:33 +0000 Received: by pzk6 with SMTP id 6so13422308pzk.8 for ; Tue, 30 Aug 2011 02:20:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.140.3 with SMTP id n3mr2948183wfd.218.1314696032910; Tue, 30 Aug 2011 02:20:32 -0700 (PDT) Received: by 10.143.13.8 with HTTP; Tue, 30 Aug 2011 02:20:32 -0700 (PDT) In-Reply-To: References: <20110830090713.GG2687@tyan-ft48-01.lab.bos.redhat.com> Date: Tue, 30 Aug 2011 10:48:00 -0000 Message-ID: Subject: Re: [PATCH] Change vcond to vcond From: Uros Bizjak To: Richard Guenther Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, uros@gcc.gnu.org, rth@redhat.com, artyom.shinkaroff@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg02426.txt.bz2 On Tue, Aug 30, 2011 at 11:15 AM, Richard Guenther wrot= e: >> >> > Hmm. =A0But then I'd have to try emit an insn, right? =A0Currently >> >> > 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? =A0If 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. >> >> OK, but in this case, do not use mode iterators too much in order to >> avoid invalid patterns. > > I don't see them as "invalid". =A0They will be unused (maybe combine > would create them though?), but they have well-defined semantics > with my proposed documentation. =A0And x86 can handle them just fine. OK, let's go this way then... We can clean up this later if at all. Uros.