On Tue, Aug 30, 2011 at 11:15 AM, Richard Guenther <rguent...@suse.de> 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. OK, let's go this way then... We can clean up this later if at all. Uros.
