On 09/24/2015 01:09 AM, Richard Biener wrote:
> 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).
Sure it's a target restriction, but it's an extremely common one. Essentially
all of our production platforms have it. What do we gain by adding some sort
of target hook for this?
> I imagine that if we expand the above to adjacent statements the CPUs can
> re-use the condition code.
Sure, but IMO it should be the job of RTL CSE to make that decision, after all
of the uses (and clobbers) of the flags register have been exposed.
> To me where the condition is in GIMPLE is an implementation detail and the
> inconveniences outweight the benefits.
Why is a 3-operand gimple statement fine, but a 4-operand gimple statement
inconvenient?
r~
