On Fri, Dec 6, 2013 at 2:10 PM, Jeff Law <l...@redhat.com> wrote: > On 11/26/13 03:52, Bin.Cheng wrote: >> >> On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law <l...@redhat.com> wrote: >>> >>> On 11/25/13 02:11, Bin.Cheng wrote: >>>> >>>> >>>> >>>> Slightly tune to make iv cand choosing algorithm more accurate: >>>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01574.html >>> >>> >>> It would help if you had some sample codes where this patch was useful. >>> I >>> can kind-of see what's going on, but I'm way too unfamiliar with the >>> tree-IV >>> code to review this change. >>> >> Jeff, Thanks to your review. >> As for example, consider below code on ARM/cortex-m4, (the code itself >> may be non-sense): > > [ ... ] > So in this testcase, it looks like the effect is to eliminate the IVs for > the loop counters, instead expressing the loop termination in terms of the > pointers. Yes, it's linear function test elimination.
> > As far as I can tell this is entirely due to the changes to iv_ca_narrow. Exactly. > > Do you have any codes where iv_ca_extend helps? I can see how that hunk > appears to be safe, and I'm guessing that setting the cost pair at each step > could potentially give more accurate costing on the next iteration of the > loop. But I'd love to be able to see this effect directly rather than just > assuming it's helpful. Given that I'm prepared to approve the iv_ca_extend > hunk. Very sorry I can't provide an example about this now. I remember it's a case in eembc I encountered, but with current trunk I can't reproduce it with the change about iv_ca_extend. Maybe recent checking has changed the behavior of IVOPT. Considering there is no case about this change, I am fine to discard this part of patch and continue with iv_ca_narrow part. > > I realize the changes to iv_ca_extend are of lesser importance, but I'm > still working my way through the tree IV code to get some basic > understanding of what it's doing and why. I hope to be able to look at > iv_ca_narrow in more detail over the weekend. Thanks very much. Thanks, bin > > jeff > > -- Best Regards.
