On Mon, 20 May 2019, 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.
Yes - my thinking was that if IVOPTs _not_ choose a doloop IV then the RTL side has to give up, so that's bad. But if it chooses a doloop IV but we end up failing to do a doloop that's not too bad. After all we indeed cannot remove RTL doloop analysis at this point. So the important thing is to make IVOPTs create a separate counter IV that is only used in the update/compare/branch and cost that appropriately (not even sure if _that_ is actually required!). A slight complication might be that if IVOPTs decides to use a doloop IV but creates another equivalent IV for other uses then later CSE might end up unifying them again. We should probably make IVOPTs aware of this. > Kewen, Bin, will that work satisfactorily do you think? > > > Segher > -- Richard Biener <rguent...@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
