[PATCH PR94125]Update post order number for merged SCC

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

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

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-object.C) before / after > >> the patch > >> (it

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

-- Sender:Richard Biener Sent At:2020 Mar. 20 (Fri.) 18:12 Recipient:bin.cheng Cc:Andrew Pinski ; GCC Patches Subject:Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums On Fri, Mar 20, 2020 at

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

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 5, 2020 at 10:18 PM Iain Sandoe wrote: > > >>> If it helps, I

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

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 approved patches. > > >> > > >> I see no change in the

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

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

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

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

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

-- 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 enumeral type in case of -fstrict-enums On Mon, Mar 2, 2020 at 6:14

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

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

On Tue, Aug 25, 2020 at 8:47 PM Kewen.Lin wrote: > > Hi Bin, > > >> > >> For one particular case like: > >> > >> for (i = 0; i < SIZE; i++) > >> y[i] = a * x[i] + z[i]; > >> > >> we will mark reg_offset_p for IV candidates on x as below: > >>- (unsigned long)

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

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

[PATCH PR93334][RFC]Skip output dep if values stored are byte wise the same

Hi, As suggested by PR93334 comments, this patch adds an interface identifying output dependence which can be skipped in terms of reordering and skip it in loop distribution. It also adds a new test case. Any comment? Thanks, bin 0001-Skip-output-dependence-if-values-stored-are-bytewise.patch

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

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

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

On Tue, Aug 18, 2020 at 5:03 PM Kewen.Lin wrote: > > Hi Bin, > > > I see, it's similar to the auto-increment case where cost should be > > recorded only once. So this is okay given 1) fine predicting > > rtl-unroll is likely impossible here; 2) the patch has very limited > > impact. > > > Really

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

On Tue, Sep 22, 2020 at 10:30 AM HAO CHEN GUI wrote: > > Bin, > > I just tested your patch on current trunk. Here is my summary. > > 1. About some iv aren't moved out of inner loop (Lijia mentioned in his > last email) > >[local count: 955630226]: ># l_32 = PHI <1(12), l_54(21)> >#

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

On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote: > > Hi Bin, > > Thanks for the review!! > > on 2020/8/8 下午4:01, Bin.Cheng wrote: > > Hi Kewen, > > Sorry for the late reply. > > The patch's most important change is below cost computation: > > > >> @@ -5890,6 +5973,10 @@ determine_iv_cost (struct

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

Hi Kewen, Sorry for the late reply. The patch's most important change is below cost computation: > @@ -5890,6 +5973,10 @@ determine_iv_cost (struct ivopts_data *data, struct > iv_cand *cand) > cost_step = add_cost (data->speed, TYPE_MODE (TREE_TYPE (base))); > cost = cost_step +

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

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

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

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

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

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: [PATCH 3/4] ivopts: Consider cost_step on different forms during unrolling

On Mon, Aug 10, 2020 at 10:41 PM Kewen.Lin wrote: > > Hi Bin, > > on 2020/8/10 下午8:38, Bin.Cheng wrote: > > On Mon, Aug 10, 2020 at 12:27 PM Kewen.Lin wrote: > >> > >> Hi Bin, > >> > >> Thanks for the review!! > >> > >> on 2020/8/8 下午4:01, Bin.Cheng wrote: > >>> Hi Kewen, > >>> Sorry for the

[PATCH PR97627]Avoid computing niters info for fake edges

Hi, As described in commit message, we need to avoid computing niters info for fake edges. This simple patch does this by two changes. Bootstrap and test on X86_64, is it ok? Thanks, bin pr97627-20210128.patch Description: Binary data

Re: [PATCH PR97627]Avoid computing niters info for fake edges

On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches wrote: > > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches > wrote: > > > > Hi, > > As described in commit message, we need to avoid computing niters info for > > fake > > edges. Thi

Re: [PATCH PR97627]Avoid computing niters info for fake edges

On Fri, Jan 29, 2021 at 3:55 PM Richard Biener wrote: > > On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote: > > > > On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches > > wrote: > > > > > > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gc

Re: [RFC] Implementing detection of saturation and rounding arithmetic

On Fri, Jun 4, 2021 at 12:35 AM Andre Vieira (lists) via Gcc-patches wrote: > > Hi, > > This RFC is motivated by the IV sharing RFC in > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569502.html and the > need to have the IVOPTS pass be able to clean up IV's shared between > multiple loops.

Re: [PATCH/RFC] Add a new memory gathering optimization for loop (PR98598)

On Fri, Apr 30, 2021 at 1:20 PM Feng Xue OS via Gcc-patches wrote: > > >> This patch implements a new loop optimization according to the proposal > >> in RFC given at > >> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html. > >> So do not repeat the idea in this mail. Hope your comments

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

On Wed, Jun 2, 2021 at 3:28 PM Richard Biener via Gcc-patches wrote: > > On Tue, Jun 1, 2021 at 4:00 PM bin.cheng via Gcc-patches > wrote: > > > > Hi, > > As described in patch summary, this fixes the wrong code issue by adding > > overflow-ness

[PATCH PR100499]Fix wrong niter info caused by overflow behavior

Hi, As described in PR100499, loop niters analysis for "!=" now relies on multiple_of_p which so far is mostly implemented for no-overflow scenarios. This patch fixes the issue by: 1. add new parameter to multiple_of_p indicating no-wrapping behavior in top expression. 2. pass new argument to

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

Hi, As described in patch summary, this fixes the wrong code issue by adding overflow-ness check for iv1.step - iv2.step. Bootstrap and test on x86_64. Any comments? Thanks, bin pr100740-20210525.txt Description: Binary data

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

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] New hook adjust_iv_update_pos

On Mon, Jun 28, 2021 at 4:26 PM Richard Biener wrote: > > On Mon, Jun 28, 2021 at 10:07 AM Xionghu Luo wrote: > > > > > > > > On 2021/6/25 18:02, Richard Biener wrote: > > > On Fri, Jun 25, 2021 at 11:41 AM Xionghu Luo wrote: > > >> > > >> > > >> > > >> On 2021/6/25 16:54, Richard Biener wrote:

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

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.

> wrote: > > > > > > > > On Tue, Jun 1, 2021 at 4:00 PM bin.cheng via Gcc-patches > > > > wrote: > > > > > > > > > > Hi, > > > > > As described in patch summary, this fixes the wrong code issue by > &

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

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

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

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.

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

On Wed, Aug 4, 2021 at 10:42 AM guojiufu wrote: > > Hi, > > I would like to have a ping on this. > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574596.html Sorry for being late in replying. > > BR, > Jiufu > > On 2021-07-15 08:17, guojiufu via Gcc-patches wrote: > > Hi, > > > > I would

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

On Wed, Aug 25, 2021 at 11:26 AM guojiufu wrote: > > On 2021-08-16 09:33, Bin.Cheng wrote: > > On Wed, Aug 4, 2021 at 10:42 AM guojiufu > > wrote: > >> > ... > >> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145.inc > >> >> b/gcc/testsuite/gcc.dg/vect/pr101145.inc > >> >> new file mode 100644

Re: [PATCH] avoid transform at run until wrap comparesion

On Thu, Sep 2, 2021 at 6:18 PM Richard Biener wrote: > > On Thu, 2 Sep 2021, Jiufu Guo wrote: > > > When transform > > {iv0.base, iv0.step} LT/LE {iv1.base, iv1.step} > > to > > {iv0.base, iv0.step - iv1.step} LT/LE {iv1.base, 0} > > > > There would be error if 'iv0.step - iv1.step' in

[PATCH AArch64]Fix expanding of %w for *extend... pattern

Hi, When playing with std::experimental::simd, I found a bug newly introduced in AArch64 backend. As commit message describes: 7 Pattern "*extend2_aarch64" is duplicated 8 from the corresponding zero_extend pattern, however % needs 9 to be expanded according to its mode iterator

Re: [committed] add test for PR 86650

On Wed, Jul 7, 2021 at 5:39 AM Martin Sebor via Gcc-patches wrote: > > The recent patch series to improve warning suppression for inlined > functions [PR98512] also implicitly includes the inlining context > in all warning messages for inlined code. In r12-2091 I have > committed the attached

Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

Gentle ping. Any suggestions would be appreciated. Thanks, bin On Wed, Jul 14, 2021 at 5:15 PM bin.cheng via Gcc-patches wrote: > > Hi, > I ran into a wrong code bug in code with deep template instantiation when > working on sdx::simd. > The root cause as described in commi

[PATCH AArch64]Use stable sort in generating ldp/stp

Hi, Like previous patch, this is found when I was playing with stx::simd. It's an obvious change as described in commit summary. Also the dead store in the code should be optimized away, but I guess there is no guarantee, so here is a simple patch fixing it. Is it OK? Thanks, bin

Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

On Fri, Jul 23, 2021 at 7:53 AM Segher Boessenkool wrote: > > On Wed, Jul 14, 2021 at 05:14:16PM +0800, bin.cheng via Gcc-patches wrote: > > Hi, > > I ran into a wrong code bug in code with deep template instantiation when > > working on sdx::simd. > > The roo

Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

On Mon, Jul 26, 2021 at 11:07 PM Jeff Law wrote: > > > > On 7/25/2021 7:47 PM, Bin.Cheng wrote: > > On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:

Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches wrote: > > > > On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote: > > Hi, > > I ran into a wrong code bug in code with deep template instantiation when > > working on sdx::simd. > > The root cause

Re: [PATCH][RFC] tree-optimization/100499 - multiple_of_p bad behavior wrt niter analysis

On Thu, Jul 22, 2021 at 6:41 PM Richard Biener wrote: > > This avoids using multiple_of_p in niter analysis when its behavior Hmm, but this patch actually introduces one more call to multiple_of_p, also it doesn't touch the below use: if (niter->control.no_overflow && multiple_of_p (type, c, s))

0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

Hi, I ran into a wrong code bug in code with deep template instantiation when working on sdx::simd. The root cause as described in commit summary is we skip prologue insns in init_alias_analysis. This simple patch fixes the issue, however, it's hard to reduce a case because of heavy use of