Kaveh R. GHAZI - Re: [PATCH]: Handle COMPLEX_EXPR in negate_expr_p/fold_negate_expr (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

On Fri, 2 Feb 2007, Richard Guenther wrote:

On 2/2/07, Kaveh R. GHAZI ghazi@caip.rutgers.edu wrote:

I don't think so, "cheaply negated" should be cheaper than (or as cheaply as) the current expression. In the example above, the expression being negated is (5,a) not -(5,a), and (5,a) is already cheaper than (-5,-a). It's only by adding the preceeding negate that you even reach cost equivalence. But the negate will not always be there, so in some cases you end up worse.

You'll pessimize code when you combine this with other existing transformations. E.g. in fold_binary, there is an existing transformation A-B -> A+(-B), if B is "cheaply negated". If you supposed the following:

(x,y) - (5,a) -> (x,y) + (-5,-a)

Now we have a plus and a negate of "a" instead of just one minus.

I'm also worried about the possibility of infinite recursion, but I haven't done an exhaustive search to find one.

Can I check in the code using the original && condition?

Yes, thanks for the further thoughts. Richard.

You're welcome. One final thought, I shouldn't have said "cost equivalence" above. In Paolo's example, it's actually a win to convert -(5,a) into (-5,-a) because the negate of a complex number has to negate twice, but the transformed case we only negate once on "a" and do "5" at compile-time.

The difference between his and my cases being:

(x,y) - (5,a) -> (x,y) + (-5,-a) BAD (2minus -> 1neg,2plus) (x,y) + -(5,a) -> (x,y) + (-5,-a) GOOD (2neg,2plus -> 1neg,2plus)

Unfortunately, I see no way currently to distinguish between these two cases in negate_expr_p unless we add some extra parameter to tell it that we're planning on deleting a wrapping NEGATE_EXPR and so it could be more liberal. Then we'd have to update all callers.

Therefore, I checked in my more conservative patch, and getting Paolo's example optimized would be IMHO a future refinement.

    Thanks,
    --Kaveh

-- Kaveh R. Ghazi ghazi@caip.rutgers.edu

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]