https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612
--- Comment #7 from amker at gcc dot gnu.org --- On powerpc32, the address candidate doesn't have the period precision to eliminate conditional iv. That's why bdn is generated. On powerpc64, the address candidate does have the period precision because the address type is of 64bit now. This reveals a missed-optimization in IVO. Currently tree level IVO doesn't know if the loop condition can be tranformed into low-overhead looping structure (using doloop). One exception is when the condition is a comparison of the candidate IV against ZERO (Even in this case, it doesn't know how much cost could be saved with doloop optimization, it just decrease the cost by a provisional const). As for this case, the loop condition is (w_3(D) > 511), which could be transformed to a comparison against ZERO in rtl level doloop optimization. Unfortunately, tree IVO knows nother about this. It's also difficult to check whether doloop is viable on GIMPLE, because there are many heuristics/fallouts in RTL transformation. I consider this as another inconsistency issue between tree IVO and rtl loop optimizers. Another example is RTL unroller messes up induction variables chosen by tree IVO. I think we could XFAIL this on powerpc64 for now. So what's your opinions? Thanks.
