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.
Thanks,
Kewen
