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 negativ
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
>
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 l
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
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:
>
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))
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
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
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
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 tes
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
0002-AArc
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
templ
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:
; 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
> &
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; +
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.
>
>
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. W
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
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
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 h
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 on
> > 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
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
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
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
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
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)>
># iv
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
D
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
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
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
>
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) (x_18(D)
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
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 late
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
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 + adjust_setu
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
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
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
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.
> >
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
--
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 10:2
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
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 testcase
--
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
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
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
47 matches
Mail list logo
