On Tue, 30 Aug 2011, Uros Bizjak wrote: > On Tue, Aug 30, 2011 at 11:07 AM, Jakub Jelinek <ja...@redhat.com> 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. > > 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". They will be unused (maybe combine would create them though?), but they have well-defined semantics with my proposed documentation. And x86 can handle them just fine. Richard.
