On 5/21/19 4:20 AM, Richard Biener wrote: > On Tue, 21 May 2019, Kewen.Lin wrote: > >> on 2019/5/21 上午12:37, Segher Boessenkool wrote: >>> On Mon, May 20, 2019 at 08:43:59AM -0600, Jeff Law wrote: >>>>> I think we should have two hooks: one is called with the struct loop as >>>>> parameter; and the other is called for every statement in the loop, if >>>>> the hook isn't null anyway. Or perhaps we do not need that second one. >>>> I'd wait to see a compelling example from real world code where we need >>>> to scan the statements. Otherwise we're just dragging in more target >>>> specific decisions which in fact we want to minimize target stuff. >>> >>> The ivopts pass will be too optimistic about what loops will end up as a >>> doloop, and cost things accordingly. The cases where we cannot later >>> actually use a doloop are doing pretty much per iteration, so I think >>> ivopts will still make good decisions. We'll need to make the rtl part >>> not actually do a doloop then, but we probably still need that logic >>> anyway. >>> >>> Kewen, Bin, will that work satisfactorily do you think? >>> >> >> If my understanding on this question is correct, IMHO we should try to make >> IVOPTs conservative than optimistic, since once the predict is wrong from >> too optimistic decision, the costing on the doloop use is wrong, it's very >> possible to affect the global optimal set. It looks we don't have any ways >> to recover it in RTL then? (otherwise, there should be better place to fix >> the PR). Although it's also possible to miss some good cases, it's at least >> as good as before, I'm inclined to make it conservative. > > I wonder if you could simply benchmark what happens if you make > IVOPTs _always_ create a doloop IV (if possible)? I doubt the > cases where a doloop IV is bad (calls, etc.) are too common and > that in those cases the extra simple IV hurts. This had been in the back of my mind as well. I wonder how the RTL IV bits would respond to that.
Jeff
