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:
>>> +/* Predict whether the given loop in gimple will be transformed in the RTL
>>> +   doloop_optimize pass.  This is for rs6000 target specific.  */
>>> +
>>> +static bool
>>> +rs6000_predict_doloop_p (struct loop *loop)
>>> +{
>>> +  gcc_assert (loop);
>>> +
>>> +  /* On rs6000, targetm.can_use_doloop_p is actually
>>> +     can_use_doloop_if_innermost.  Just ensure it's innermost.  */
>>
>> So the point is that ppc only has a single counter register, right?
> 
> That, and the register is call-clobbered, and some RTL patterns use it
> for other purposes.  So we want doloop only for inner loops, and not if
> certain constructs are used in the loop (switch statements...)
> 
> It may be good enough if we only look at the loop structure?  That would
> simplify things a lot ;-)
That seems reasonable to me.  My recollection is that most other targets
with low overhead loops have a single counter register.  THe most
obvious counter example would be m68k, but that's a don't care IMHO.


> 
>> 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.

jeff

Reply via email to