Hi Bin, > I am a bit worried that would make IVOPTs heavy too, it might be > possible to compute heuristics whether loop should be unrolled as a > post-IVOPTs transformation. Of course the transformation needs to do > more work than simply unrolling in order to take advantage of > aforementioned addressing mode.
Agreed, I prefer to just figure out the unroll factor (UF) by some heurisitcs instead of performing actual unrolling as well. I guess "post-IVOPTs" is a typo for "pre-IVOPTs"? > BTW, unrolled loop won't perform as good as ppc if the target doesn't > support [base + register + offset] addressing mode? > The target which doesn't support D-form would probably have benefits from unrolling, but IVOPTs decision won't affect it since X-form doesn't have offset field to hide step updates. In the next patch, I'll compute UF with moreheurisitics and update IV cand step cost with that, for D-form cand, just one time step_cost, but for X-form cand, it would be UF*step_cost. > Another point, in case of multiple passes doing unrolling, the > "already unrolled" information may need to be recorded as a flag of > loop properties. Yes, we can update the computed UF into loop struct unroll field. I'll check performance impact to avoid the proposed UF computation is poor. Thanks, Kewen
