On Tue, May 21, 2019 at 1:50 PM Kewen.Lin <li...@linux.ibm.com> wrote: > > on 2019/5/20 下午10:43, Jeff Law wrote: > > On 5/20/19 4:24 AM, Segher Boessenkool wrote: > >> Let me try to answer a bit here... > >> > >> On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote: > >>> On Thu, 16 May 2019, li...@linux.ibm.com wrote: > >> > >>> So the better way would be to expose that via a target hook somehow. > >>> Or simply restrict IVOPTs processing to innermost loops for now. > >> > >> 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 scan is trying to do similar thing like default_invalid_within_doloop. > It scans for hardware counter register clobbering. I think it's important > and valuable to scan especially for call since it's common. > > if (CALL_P (insn)) > return "Function call in loop."; > > if (tablejump_p (insn, NULL, NULL) || computed_jump_p (insn)) > return "Computed branch in the loop."; > > But it's a question whether to make it as part of generic. I double checked > that most of the doloop targets use this default behavior, only 5 targets are > using their own TARGET_INVALID_WITHIN_DOLOOP, so it might be a good thing to > make it common to share. I was not following previous rounds of discussion. But again, is it possible to make all code(including scanning every stmt in every bb in loop, as well as niter checks) generic, export a target hook checking on gimple_stmt. In this case, backends could still make their own decision?
Thanks, bin > > > Thanks, > Kewen >
