From: Richard Guenther <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>,
gcc-patches@gcc.gnu.org, uros@gcc.gnu.org, rth@redhat.com,
artyom.shinkaroff@gmail.com
Subject: Re: [PATCH] Change vcond<mode> to vcond<mode1><mode2>
Date: Tue, 30 Aug 2011 09:39:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1108301109170.2130@zhemvz.fhfr.qr> (raw)
In-Reply-To: <20110830090713.GG2687@tyan-ft48-01.lab.bos.redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1530 bytes --]
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<mode> where
mode is the comparison and mask mode, a convert-move and a
vapplycondmask<mode> 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.
next prev parent reply other threads:[~2011-08-30 9:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 15:08 Richard Guenther
2011-08-29 16:36 ` Richard Guenther
2011-08-29 20:47 ` Uros Bizjak
2011-08-29 21:05 ` Richard Guenther
2011-08-30 9:00 ` Uros Bizjak
2011-08-30 9:19 ` Richard Guenther
2011-08-30 9:24 ` Uros Bizjak
2011-08-30 9:29 ` Jakub Jelinek
2011-08-30 9:39 ` Richard Guenther [this message]
2011-08-30 9:42 ` Uros Bizjak
2011-08-30 10:17 ` Richard Guenther
2011-08-30 10:48 ` Uros Bizjak
2011-08-30 11:59 ` Richard Guenther
2011-08-30 12:11 ` Richard Guenther
2011-09-02 9:44 ` Richard Guenther
2011-09-02 12:19 ` Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1108301109170.2130@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=artyom.shinkaroff@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=rth@redhat.com \
--cc=ubizjak@gmail.com \
--cc=uros@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).