This is the mail archive of the
mailing list for the GCC project.
Re: why no shortcut operation for comparion on _Complex operands
On Tue, Mar 27, 2012 at 8:01 AM, Bin.Cheng <email@example.com> wrote:
> On Mon, Mar 26, 2012 at 3:27 PM, Richard Guenther
> <firstname.lastname@example.org> wrote:
>> On Sun, Mar 25, 2012 at 2:42 PM, Bin.Cheng <email@example.com> wrote:
>>> 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>;
>>> ? ?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
For the particluar case a better lowering from tree-complex.c is desired
(I can imagine even using vector instructions ..). It probably was just easiest
to not to have to alter the CFG at this point.
> Best Regards.