From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15026 invoked by alias); 30 Aug 2011 09:02:19 -0000 Received: (qmail 15015 invoked by uid 22791); 30 Aug 2011 09:02:17 -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:02:03 +0000 Received: by pzk6 with SMTP id 6so13392695pzk.8 for ; Tue, 30 Aug 2011 02:02:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.180.19 with SMTP id c19mr1190217wff.104.1314694922712; Tue, 30 Aug 2011 02:02:02 -0700 (PDT) Received: by 10.143.13.8 with HTTP; Tue, 30 Aug 2011 02:02:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Aug 2011 09:24:00 -0000 Message-ID: Subject: Re: [PATCH] Change vcond to vcond From: Uros Bizjak To: Richard Guenther Cc: 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/msg02420.txt.bz2 On Tue, Aug 30, 2011 at 10:50 AM, Richard Guenther wrot= e: >> > Hm, ok - that was the first variant I tried (well, but with modeless >> > operands 1 and 2, to keep 4 and 5 selcting int vs. fp compare). =A0But >> > modeless operands get you that annoying warning from the gen* programs. >> >> Only for define_insn, if your c_test does not include string "operands". >> >> > How'd you ask if a pattern is available for vcondv4si with v4sf >> > operands 4 and 5? =A0The vectorizer would need to be able to ask this >> > question. >> >> Maybe with something along the lines of: >> >> (define_expand "vcond" >> =A0 [(set (match_operand:VI124_128 0 "register_operand" "") >> =A0 =A0 =A0 (if_then_else:VI124_128 >> =A0 =A0 =A0 =A0 (match_operator 3 "" >> =A0 =A0 =A0 =A0 =A0 [(match_operand 4 "nonimmediate_operand" "") >> =A0 =A0 =A0 =A0 =A0 =A0(match_operand 5 "nonimmediate_operand" "")]) >> =A0 =A0 =A0 =A0 (match_operand:VI124_128 1 "general_operand" "") >> =A0 =A0 =A0 =A0 (match_operand:VI124_128 2 "general_operand" "")))] >> =A0 "TARGET_SSE2" >> { >> =A0 if (GET_MODE (operands[4]) !=3D GET_MODE (operands[5]) >> =A0 =A0 =A0 || (GET_MODE_NUNITS (GET_MODE (operands[4])) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !=3D GET_MODE_NUNITS (GET_MODE (operands= [0])))) >> =A0 =A0 FAIL; >> >> =A0 bool ok =3D ix86_expand_int_vcond (operands); >> =A0 gcc_assert (ok); >> =A0 DONE; >> }) >> >> This means that vcond pattern is allowed to FAIL, so when vectorizer >> tentatively tries to expand the pattern, FAIL signalizes that operand >> modes are not supported. > > 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. > That shifts the ugliness towards the users, for just saving > a few redundant patterns? I think that hook solves this in the most elegant way. Uros.