why no shortcut operation for comparion on _Complex operands

[Bin.Cheng]

On Mon, Mar 26, 2012 at 3:27 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sun, Mar 25, 2012 at 2:42 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> Hi,
>> In tree-complex.c's function expand_complex_comparison, gcc just
>> expand comparison on complex
>> operands into comparisons on inner type, like:
>>
>>  D.5375_17 = REALPART_EXPR <g2>;
>>  D.5376_18 = IMAGPART_EXPR <g2>;
>>  g2.1_5 = COMPLEX_EXPR <D.5375_17, D.5376_18>;
>>  D.5377_19 = REALPART_EXPR <g3>;
>>  D.5378_20 = IMAGPART_EXPR <g3>;
>>  g3.2_6 = COMPLEX_EXPR <D.5377_19, D.5378_20>;
>>  D.5379_21 = D.5375_17 == D.5377_19;
>>  D.5380_22 = D.5376_18 == D.5378_20;
>>  D.5381_23 = D.5379_21 & D.5380_22;
>>  if (D.5381_23 == 1)
>>    goto <bb 3>;
>>  else
>>    goto <bb 4>;
>>
>> So is it possible to do shortcut operation for the "&" on the
>> real/imag part of complex data?
>
> Sure.  Does the RTL expander not do that for your target?

Yes, expand_gimple_cond decides how to expand such codes.
And, it depends on BRANCH_COST whether codes will be expanded into
shortcut operations. true for X86, false for arm at least.
I am wondering, should we take a more general strategy, rather than just
branch cost heuristic decision.
The new strategy should compare the cost of operation and branch, e.g.,
On target has no hard float instructions, comparison of float point should be
shortcuted, since the helper function is very expensive.

Any idea? Thanks
-- 
Best Regards.