This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Change vcond<mode> to vcond<mode1><mode2>
On Tue, Aug 30, 2011 at 10:50 AM, Richard Guenther <rguenther@suse.de> wrote:
>> > 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). ?But
>> > 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? ?The vectorizer would need to be able to ask this
>> > question.
>>
>> Maybe with something along the lines of:
>>
>> (define_expand "vcond<mode>"
>> ? [(set (match_operand:VI124_128 0 "register_operand" "")
>> ? ? ? (if_then_else:VI124_128
>> ? ? ? ? (match_operator 3 ""
>> ? ? ? ? ? [(match_operand 4 "nonimmediate_operand" "")
>> ? ? ? ? ? ?(match_operand 5 "nonimmediate_operand" "")])
>> ? ? ? ? (match_operand:VI124_128 1 "general_operand" "")
>> ? ? ? ? (match_operand:VI124_128 2 "general_operand" "")))]
>> ? "TARGET_SSE2"
>> {
>> ? if (GET_MODE (operands[4]) != GET_MODE (operands[5])
>> ? ? ? || (GET_MODE_NUNITS (GET_MODE (operands[4]))
>> ? ? ? ? ? ? ? ? != GET_MODE_NUNITS (GET_MODE (operands[0]))))
>> ? ? FAIL;
>>
>> ? bool ok = ix86_expand_int_vcond (operands);
>> ? gcc_assert (ok);
>> ? 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. ?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.
> 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.