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.
