On Sun, 5 May 2019, Kewen.Lin wrote:
> on 2019/4/27 上午11:44, Bin.Cheng wrote:
> > GCC lacks the capability passing information to later passes. Gimple
> > analyzer worked hard collecting various information but discards it
> > entering RTL or earlier. Other examples are like runtime alias
> > in
on 2019/5/6 上午9:50, Bin.Cheng wrote:
> On Sun, May 5, 2019 at 2:02 PM Kewen.Lin wrote:
>>
>> To decrease the cost isn't workable for this case, it make the original
>> iv cand is preferred more and over the other iv cand for memory iv use,
>> then the desirable memory based iv cand won't be chosen
On Sun, May 5, 2019 at 2:02 PM Kewen.Lin wrote:
>
> on 2019/5/5 下午12:04, Bin.Cheng wrote:
> > On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
> + /* Some compare iv_use is probably useless once the doloop
> optimization
> + performs. */
> + if (tailor_cmp_p)
> +
On Sun, May 05, 2019 at 12:04:00PM +0800, Bin.Cheng wrote:
> On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
> > I can't really follow this. If it's predicted to be transformed to doloop,
> > I think it should not be undoed any more, since it's useless to consider
> > this cmp iv use. Whatever I
on 2019/5/5 下午12:04, Bin.Cheng wrote:
> On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
+ /* Some compare iv_use is probably useless once the doloop optimization
+ performs. */
+ if (tailor_cmp_p)
+tailor_cmp_uses (data);
>>> Function tailor_cmp_uses sets iv_use->ze
on 2019/4/27 上午11:44, Bin.Cheng wrote:
> On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>> +
>> + /* zero cost use makes it easier to select memory based iv cand
>> + for replacement of non memory based iv and its use. But if
>> + the setup sequence are too costly, loop iv
On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> Sorry for late response (just back from vacation).
>
> Thanks very much for your comments.
>
> on 2019/4/27 上午11:20, Bin.Cheng wrote:
> > For such non-trivial patch, we can improve review process by splitting
> > to smaller patches w
on 2019/4/27 上午12:59, Segher Boessenkool wrote:
> On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
>> on 2019/4/26 下午3:16, Richard Biener wrote:
>>> We should think about possible ways of encoding doloop at IVOPTs
>>> time rather than trying to re-analyze at RTL. I suppose we can
>>> eas
Hi Bin,
Sorry for late response (just back from vacation).
Thanks very much for your comments.
on 2019/4/27 上午11:20, Bin.Cheng wrote:
> For such non-trivial patch, we can improve review process by splitting
> to smaller patches which can be reviewed/approved independently.
Good idea! I'll split
On Fri, Apr 26, 2019 at 2:44 PM Kewen.Lin wrote:
>
> Hi Segher,
>
> Thanks a lot for your comments!
>
> on 2019/4/25 下午8:16, Segher Boessenkool wrote:
>
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
Thanks very much for working on this.
On Wed, Apr 24, 2019 at 4:41 PM Kewen.Lin wrote:
>
> Hi all,
>
> As PR80791 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791, on
> some targets which support low-overhead loop, the related compare
> type ivs use is possible to become dead and removed eventu
On Fri, Apr 26, 2019 at 07:51:05PM +0200, Richard Biener wrote:
> On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool
> wrote:
> >So, make it a doloop in gimple, and still have the rtl pass, but that
> >only reverts it to a non-doloop if it turns out it has to. Does that
> >sound like a g
On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool
wrote:
>On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
>> on 2019/4/26 下午3:16, Richard Biener wrote:
>> > We should think about possible ways of encoding doloop at IVOPTs
>> > time rather than trying to re-analyze at RTL. I s
On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
> on 2019/4/26 下午3:16, Richard Biener wrote:
> > We should think about possible ways of encoding doloop at IVOPTs
> > time rather than trying to re-analyze at RTL. I suppose we can
> > easily set a flag in struct loop but I'm not familiar
On Fri, Apr 26, 2019 at 02:43:44PM +0800, Kewen.Lin wrote:
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
> > Maybe you can show the generated code?
>
> It's a good question! From the generated codes
on 2019/4/26 下午3:16, Richard Biener wrote:
> On Fri, 26 Apr 2019, Kewen.Lin wrote:
>
>> I was thinking whether this zero cost change just exposed
>> an existing problem, then this kind of check should be for all
>> cases not only for zero cost use, similar to
>> expression_expensive_p? But wh
On Fri, 26 Apr 2019, Kewen.Lin wrote:
> Hi Segher,
>
> Thanks a lot for your comments!
>
> on 2019/4/25 下午8:16, Segher Boessenkool wrote:
>
> > Does it create worse code now? What we have before your patch isn't
> > so super either (it has an sldi in the loop, it has two mtctr too).
> > Maybe
Hi Segher,
Thanks a lot for your comments!
on 2019/4/25 下午8:16, Segher Boessenkool wrote:
> Does it create worse code now? What we have before your patch isn't
> so super either (it has an sldi in the loop, it has two mtctr too).
> Maybe you can show the generated code?
It's a good question!
Hi Kewen,
Cool stuff.
On Wed, Apr 24, 2019 at 04:41:01PM +0800, Kewen.Lin wrote:
> One failure was found in regression testing, which is:
> gcc.target/powerpc/20050830-1.c
>
> I did some investigation and found: with this patch, one new iv cand
> is chosen for exit condition, which is used to
Thanks for catching, Jakub!
The update listed below, will integrate it with next revision patch.
gcc/ChangeLog
2019-04-24 Kewen Lin
PR middle-end/80791
* target.def (predict_doloop_p): New hook.
* targhooks.h (default_predict_doloop_p): New declaration.
* tar
On Wed, Apr 24, 2019 at 04:41:01PM +0800, Kewen.Lin wrote:
> gcc/ChangeLog
Not a review, just ChangeLog nits.
> 2019-04-24 Kewen Lin
>
> PR middle-end/80791
> * target.def (predict_doloop_p): New.
> * targhooks.h (default_predict_doloop_p): New.
> * targhooks.c (defaul
Hi all,
As PR80791 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791, on
some targets which support low-overhead loop, the related compare
type ivs use is possible to become dead and removed eventually.
However, the current ivopt cost modeling doesn't consider this
possible elimination, it leads
22 matches
Mail list logo
