Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

2020-09-01 Thread Bin.Cheng via Gcc-patches
On Wed, Sep 2, 2020 at 11:50 AM Kewen.Lin wrote: > > Hi Bin, > > >> 2) This case makes me think we should exclude ainc candidates in function > >> mark_reg_offset_candidates. The justification is that: ainc candidate > >> handles step update itself and when we calculate the cost for it against >

Re: [PATCH 3/4 v3] ivopts: Consider cost_step on different forms during unrolling

2020-09-04 Thread Bin.Cheng via Gcc-patches
On Fri, Sep 4, 2020 at 6:37 AM Segher Boessenkool wrote: > > On Thu, Sep 03, 2020 at 10:24:21AM +0800, Kewen.Lin wrote: > > on 2020/9/2 下午6:25, Segher Boessenkool wrote: > > > On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote: > > >> on 2020/9/1 上午3:41, Segher Boessenkool wrote: > > >>> On

Re: Do we need to do a loop invariant motion after loop interchange ?

2020-09-08 Thread Bin.Cheng via Gcc-patches
On Mon, Sep 7, 2020 at 5:42 PM HAO CHEN GUI wrote: > > Hi, > > I want to follow Lijia's work as I gained the performance benefit on > some SPEC workloads by adding a im pass after loop interchange. Could > you send me the latest patches? I could do further testing. Thanks a lot. Hi, Hmm, not sure

[PATCH PR94125]Update post order number for merged SCC

2020-03-14 Thread bin.cheng via Gcc-patches
Hi, This simple patch fixes PR94125 by updating post order number for merged SCC. The root cause is after computing SCC with runtime alias edges skipped, the post order info is changed and it's possible a partition is scheduled after another where should be scheduled before. Note that updating to

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

2020-03-16 Thread Bin.Cheng via Gcc-patches
On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > > Bin.Cheng wrote: > > > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > >> With current trunk + Bin’s two approved patches. > >> > >> I see no change in the testcase (lambda-09-capture-obje

Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

2020-03-20 Thread bin.cheng via Gcc-patches
PM Andrew Pinski wrote: > > On Mon, Mar 2, 2020 at 1:40 AM Richard Biener > wrote: > > > > On Mon, Mar 2, 2020 at 9:07 AM bin.cheng > > wrote: > > > > > > Hi, > > > This is a simple fix for PR93674. It adds cand carefully for enumeral >

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

2020-03-25 Thread Bin.Cheng via Gcc-patches
On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: > > On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > > > > Bin.Cheng wrote: > > > > > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: > > > > >> With current trunk + Bin’s two app

[PATCH PR95804]Force reduction partition to be scheduled in the last

2020-07-07 Thread bin.cheng via Gcc-patches
Hi, This is a followup fix for PR95638 which changed the way post order numbers are maintained for partition graph. It missed one case that when SCC of reduction partition is broken by runtime alias checks, we do need to make sure the reduction partition be scheduled in the last. This patch do

Re: [PATCH v2] genemit.c (main): split insn-emit.c for compiling parallelly

2020-07-20 Thread Bin.Cheng via Gcc-patches
On Tue, Jul 21, 2020 at 11:14 AM Jojo wrote: > > gcc/ChangeLog: > > * genemit.c (main): Print 'split line'. > * Makefile.in (insn-emit.c): Define split count and file > Thanks for working one this, following comments are based on the assumption that the approach is feasible after

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

2020-04-08 Thread Bin.Cheng via Gcc-patches
On Tue, Apr 7, 2020 at 11:45 PM Iain Sandoe wrote: > > Bin.Cheng wrote: > > > On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote: > >> On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote: > >>> Bin.Cheng wrote: > >>> > >>>> On Thu, Mar

Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

2020-04-08 Thread bin.cheng via Gcc-patches
:27 AM bin.cheng wrote: > > -- > Sender:Richard Biener > Sent At:2020 Mar. 3 (Tue.) 17:36 > Recipient:Andrew Pinski > Cc:bin.cheng ; GCC Patches > > Subject:Re: [PATCH PR93674]Avoid introducing IV of

[PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions

2020-05-10 Thread bin.cheng via Gcc-patches
Hi, As analyzed in PR94969, data dependence analysis now misses dependence vector for specific case in which DRs in DDR have the same invariant access functions. This simple patch fixes the issue by also covering invariant cases. Bootstrap and test on x86_64, is it OK? Thanks, bin 2020-05-11

Re: [PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions

2020-05-13 Thread Bin.Cheng via Gcc-patches
On Thu, May 14, 2020 at 1:46 AM Jakub Jelinek via Gcc-patches wrote: > > On Wed, May 13, 2020 at 02:00:11PM +0200, Christophe Lyon via Gcc-patches > wrote: > > > > 2020-05-11 Bin Cheng > > > > > > > > PR tree-optimization/94969 > > > > * gcc.dg/tree-ssa/pr94969.c: New test. > >

[PATCH PR95638]Record/restore postorder, rather than update it

2020-06-15 Thread bin.cheng via Gcc-patches
Hi, This simple patch fixes wrong code issue as reported. I tried to update postorder information after the second call to graphds_scc with alias dependence edges skipped. This wasn't working, and I realize it's hard to do. This patch simply records postorder information before the call and r

[PATCH RFC][PR98736]Compute and use programing order preserved RPO in loop distribution

2021-03-22 Thread bin.cheng via Gcc-patches
Hi, This is the patch for PR98736. The root cause is like: Use programing order preserved RPO in loop distribution. Tree loop distribution uses RPO to build reduced dependence graph, it's important that RPO preserves the original programing order and usually it does. Howeve

Re: [PATCH RFC][PR98736]Compute and use programing order preserved RPO in loop distribution

2021-03-23 Thread bin.cheng via Gcc-patches
> > In the patch, I just duplicated and created new function > > loop_first_rev_post_order_compute_fn. > > I am not sure if I should change the original function > > pre_and_rev_post_order_compute_fn > > (maybe not at this stage)? I am neither sure about the name, though haven't > > got a better

Re: [PATCH] Analyze niter for until-wrap condition [PR101145]

2021-07-01 Thread Bin.Cheng via Gcc-patches
On Thu, Jul 1, 2021 at 10:06 AM Jiufu Guo via Gcc-patches wrote: > > For code like: > unsigned foo(unsigned val, unsigned start) > { > unsigned cnt = 0; > for (unsigned i = start; i > val; ++i) > cnt++; > return cnt; > } > > The number of iterations should be about UINT_MAX - start. > >

Re: [PATCH] Analyze niter for until-wrap condition [PR101145]

2021-07-01 Thread Bin.Cheng via Gcc-patches
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches wrote: > > On 2021-07-01 20:35, Richard Biener wrote: > > On Thu, 1 Jul 2021, Jiufu Guo wrote: > > > >> For code like: > >> unsigned foo(unsigned val, unsigned start) > >> { > >> unsigned cnt = 0; > >> for (unsigned i = start; i > val; +

Re: [PATCH PR100740]Fix overflow check in simplifying exit cond comparing two IVs.

2021-07-01 Thread Bin.Cheng via Gcc-patches
On Thu, Jul 1, 2021 at 8:19 PM Richard Biener wrote: > > On Mon, Jun 7, 2021 at 4:35 PM Richard Biener > wrote: > > > > On Sun, Jun 6, 2021 at 12:01 PM Bin.Cheng wrote: > > > > > > On Wed, Jun 2, 2021 at 3:28 PM Richard Biener via Gcc-patches > > >

<    5   6   7   8   9   10