On Thu, Jul 9, 2015 at 5:49 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Jul 9, 2015 at 11:37 AM, Bin Cheng <bin.ch...@arm.com> wrote: >> Hi, >> When I going through the code, I spot this minor issue. When >> start_cand/orig_cand/third_cand have overall cost in order like "start_cand >> < third_cand < orig_cand", GCC chooses the third_cand instead of start_cand >> because we haven't set best_cost for start_cand. This is an obvious fix to >> it. >> >> So is it OK? > > Ok. I wonder if you have a testcase which this improves? Thanks for reviewing. No, unfortunately. I ran into a case with another patch. Even for that case, the start_cand has same overall cost with third_cand. But I believe the idea is true. Considering if we didn't handle start_cand specially (well, we need to handle it specially) in narrowing, we need to check it for possible lower cost in following loop anyway.
Thanks, bin > > Richard. > >> >> 2015-07-08 Bin Cheng <bin.ch...@arm.com> >> >> * tree-ssa-loop-ivopts.c (iv_ca_narrow): Update best_cost >> if start candidate has lower cost.
