On Tue, May 21, 2019 at 02:03:04PM +0800, 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.
Ah, it does change what is chosen, and it happens a lot as well... So never mind, this is one simplification too far :-) > It looks we don't have any ways to recover it in RTL then? We don't. We'd have to redo everything that happened in between... > (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. Segher
