[PATCH v3 2/3] Add predict_doloop_p target hook

Kewen.Lin linkw@linux.ibm.com
Wed May 22 02:07:00 GMT 2019


on 2019/5/21 脧脗脦莽6:20, Richard Biener wrote:
> On Tue, 21 May 2019, 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.  It looks we don't have any ways
>> to recover it in RTL then?  (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.
> 
> I wonder if you could simply benchmark what happens if you make
> IVOPTs _always_ create a doloop IV (if possible)?  I doubt the
> cases where a doloop IV is bad (calls, etc.) are too common and
> that in those cases the extra simple IV hurts.
> 

OK.  I'll do the changes and measure with SPEC2017.  Maybe also 
extend it to two other checks niter cost check and estimated
niter range check.  It may take some days.  You might have to
expect late response.  :)


Thanks
Kewen


> Richard.
> 



More information about the Gcc-patches mailing list