On Wed, Sep 23, 2015 at 8:44 PM, Richard Henderson <r...@redhat.com> wrote:
> On 09/23/2015 06:53 AM, Richard Biener wrote:
>> I think independent improvements are
>>
>> 1) remove (most) of the bool patterns from the vectorizer
>>
>> 2) make VEC_COND_EXPR not have a GENERIC comparison embedded
>>
>> (same for COND_EXPR?)
>
> Careful.
>
> The reason that COND_EXPR have embedded comparisons is to handle flags
> registers. You can't separate the setting of the flags from the using of the
> flags on most targets, because there's only one flags register.
>
> The same is true for VEC_COND_EXPR with respect to MIPS. The base
> architecture
> has 8 floating-point comparison result flags, and the vector compare
> instructions are fixed to set fcc[0:width-1]. So again there's only one
> possible output location for the result of the compare.
>
> MIPS is going to present a problem if we attempt to generalize logical
> combinations of these vector<bool>, since one has to use several instructions
> (or one insn and pre-load constants into two registers) to get the fcc bits
> out
> into a form we can manipulate.
Both are basically a (target) restriction on how we should expand a conditional
move (and its condition). It's techincally convenient to tie both together by
having them in the same statement but it's also techincally very incovenient
in other places. I'd say for targets where
tem_1 = a_2 < b_3;
res_4 = tem_1 ? c_5 : d_6;
res_7 = tem_1 ? x_8 : z_9;
presents a serious issue ("re-using" the flags register) out-of-SSA
should duplicate
the conditionals so that TER can do its job (and RTL expansion should use TER
to get at the flags setter). I imagine that if we expand the above to
adjacent statements
the CPUs can re-use the condition code.
To me where the condition is in GIMPLE is an implementation detail and the
inconveniences outweight the benefits.
Maybe we should make the effects of TER on the statement schedule explicitely
visible to make debugging that easier and remove the implicit scheduling from
the SSA name expansion code (basically require SSA names do have expanded defs).
That way we have the chance to perform pre-expansion "scheduling" in a more
predictable way leaving only the parts of the expansion using TER that want to
see a bigger expression (like [VEC_]COND_EXPR expansion eventually).
Richard.
>
> r~
