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/tes
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:
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
> > >
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
h works fine. Could you please add it into trunk? Thanks
> a lot.
Hmm, IIRC the patch was intended to show what the missing transform
is, and I think it has latent bugs which I haven't got time to refine.
As Richard mentioned, could you please explore this with the existing
LIM facility, rather
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 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:
> >
> &
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
: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
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
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
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
>
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
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
On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote:
>
> Hello JunMa,
>
> JunMa wrote:
>
> > Ping
>
> Once again, sorry for taking time to review this.
>
> > 在 2020/2/27 上午10:18, JunMa 写道:
> >> 在 2020/2/11 上午10:14, JunMa 写道:
> >> Kindly ping
> >>
> >> Regards
> >> JunMa
> >>> Hi
> >>> In maybe_prom
Forwarding to public list.
-- Forwarded message -
From: Bin.Cheng
Date: Mon, Mar 9, 2020 at 5:07 PM
Subject: Re: [PATCH PR93674]Avoid introducing IV of enumeral type in
case of -fstrict-enums
To: Richard Biener
On Tue, Mar 3, 2020 at 5:36 PM Richard Biener
wrote:
>
>
Hi,
This is a simple fix for PR93674. It adds cand carefully for enumeral type
iv_use in
case of -fstrict-enums, it also avoids computing, replacing iv_use with the
candidate
so that no IV of enumeral type is introduced with -fstrict-enums option.
Testcase is also added. Bootstrap and test on
Ping.
Thanks,
bin
On Mon, Feb 3, 2020 at 1:55 PM bin.cheng wrote:
>
> Hi,
>
> Exception in coroutine is not correctly handled because the default
> return_void call is now inserted before the finish suspend point,
> rather than at the end of the original coroutine body. This
Hi,
We found more ICEs because of unexpanded CO_AWAIT_EXPR, it turned out we
can fix these issues with more simplification in function co_await_expander.
Here
is the patch with a new test.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
gcc/cp
2020-02-10 Bin Cheng
* coroutine
On Thu, Feb 6, 2020 at 5:12 PM Iain Sandoe wrote:
>
> Hi JunMa,
>
> JunMa wrote:
>
> > 在 2020/2/4 下午8:17, JunMa 写道:
> >> Hi
> >> When testing coroutines with lambda function, I find we copy each captured
> >> variable to frame. However, according to gimplify pass, for each
> >> declaration
> >> t
Hi,
This is an obvious patch fixing typo in maybe_promote_captured_temps,
previously, the vnum (== 0) is used for all captured temps...
Will commit later.
Thanks,
bin
gcc/cp
2020-02-05 Bin Cheng
* coroutines.cc (maybe_promote_captured_temps): Increase the index
number for tem
Hi,
This simple patch actually is a missing part of previous one at
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01451.html
It picks up more CO_AWAIT_EXPR expanding cases. Test is also added.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
gcc/cp
2020-02-05 Bin Cheng
* coroutin
Hi,
Exception in coroutine is not correctly handled because the default
return_void call is now inserted before the finish suspend point,
rather than at the end of the original coroutine body. This patch
fixes the issue by generating following code:
co_await promise.initial_suspend();
try {
On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs wrote:
>
> On 29/01/2020 08:24, Richard Biener wrote:
> > On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs wrote:
> >>
> >> This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn.
> >>
> >> The problem is that an "iv" is created in which both b
Hi,
As discussed in the PR, this simple patch refines data dependence of two write
references storing the same constant with the same bytes. It simply detects
the case with some restrictions and treats it as no dependence. For now the
added interface in tree-data-ref.c is only used in loop distr
Hi,
Though function co_await_expander may need to be further revised, this simple
patch fixes an ICE case in co_await_expander,
Handle CO_AWAIT_EXPR in conversion in co_await_expander.
Function co_await_expander expands CO_AWAIT_EXPR and inserts expanded
code before result of c
On Mon, Jan 20, 2020 at 10:59 PM Iain Sandoe wrote:
>
> Hi Bin,
>
> bin.cheng wrote:
>
> > By standard, coroutine body should be encapsulated in try-catch block
> > as following:
> > try {
> > // coroutine body
> > } catch(...) {
> > pr
Hi,
By standard, coroutine body should be encapsulated in try-catch block
as following:
try {
// coroutine body
} catch(...) {
promise.unhandled_exception();
}
Given above try-catch block is implemented in the coroutine actor
function called by coroutine ramp function, so the promise
On Mon, Jan 20, 2020 at 6:31 PM Iain Sandoe wrote:
>
> Hi Bin,
>
> Bin.Cheng wrote:
>
> > On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
> >> On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> >>> Hi Bin,
> >>>
> >>
On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
>
> On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> > Hi Bin,
> >
> > bin.cheng wrote:
> >
> > > gcc/cp
> > > 2020-01-20 Bin Cheng
> > >
> > >
Hi,
This simple patch skips calling complete_type_or_else for void type, which
fixes the
corresponding ICE.
Thanks,
bin
gcc/cp
2020-01-20 Bin Cheng
* coroutines.cc (build_co_await): Skip getting complete type for void.
gcc/testsuite
2020-01-20 Bin Cheng
* g++.dg/corouti
Hi,
The patch sets current_function_returns_value flag in templates for all
co_return/co_yield/co_await cases, as well as for ramp function. This
fixes false warning message for case like the added, or various cases in
cppcoro.
Bootstrap and test on X86_64, is it OK?
Thanks,
bin
gcc/cp
2020-01
> > + gassign *get_res = gimple_build_assign (lhs, done);
> > + gsi_replace (gsi, get_res, true);
> > + *handled_ops_p = true;
> > + }
> > + break;
> > + }
> > +}
> > + return NULL_TREE;
> > +}
> > +
> > +/* Main entry point for lowering coro
On Wed, Jan 15, 2020 at 5:04 AM Jeff Law wrote:
>
> On Thu, 2020-01-09 at 14:20 +0800, Bin.Cheng wrote:
> > On Fri, Dec 20, 2019 at 3:10 PM Richard Biener
> > wrote:
> > > On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
> > > wrote:
>
--
Sender:Richard Biener
Sent At:2020 Jan. 9 (Thu.) 20:01
Recipient:Bin.Cheng
Cc:bin.cheng ; GCC Patches
Subject:Re: [PATCH GCC11]Improve uninitialized warning with value range info
On Thu, Jan 9, 2020 at 11:17 AM Bin.Cheng
On Wed, Jan 8, 2020 at 7:50 PM Richard Biener
wrote:
>
> On Wed, Jan 8, 2020 at 12:30 PM Bin.Cheng wrote:
> >
> > On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Jan 8, 2020 at 6:01 AM bin.cheng
> > &
On Fri, Dec 20, 2019 at 3:10 PM Richard Biener
wrote:
>
> On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
> wrote:
> >On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
> > wrote:
> >>
> >> Hi,
> >>
> >> As reported in P
On Wed, Jan 8, 2020 at 6:31 PM Richard Biener
wrote:
>
> On Wed, Jan 8, 2020 at 6:01 AM bin.cheng wrote:
> >
> > Sorry, here is the patch.
> > --
> > Sender:bin.cheng
> > Sent At:2020 Jan. 8 (W
On Tue, Jan 7, 2020 at 6:48 PM Kewen.Lin wrote:
>
> on 2020/1/7 下午5:14, Richard Biener wrote:
> > On Mon, 6 Jan 2020, Kewen.Lin wrote:
> >
> >> We are thinking whether it can be handled in IVOPTs instead of one RTL
> >> pass.
> >>
> >> During IVOPTs selecting IV cands, it doesn't know the loop wi
Sorry, here is the patch.
--
Sender:bin.cheng
Sent At:2020 Jan. 8 (Wed.) 12:58
Recipient:GCC Patches
Subject:[PATCH GCC11]Improve uninitialized warning with value range info
Hi,
Function use_pred_not_overlap_with_undef_path_pred o
Hi,
Function use_pred_not_overlap_with_undef_path_pred of
pass_late_warn_uninitialized
checks if predicate of variable use overlaps with predicate of undefined
control flow path.
For now, it only checks ssa_var comparing against constant, this can be
improved where
ssa_var compares against anot
On Fri, Dec 13, 2019 at 11:26 AM bin.cheng wrote:
>
> Hi,
>
> As reported in PR92926, constant ctor is shared translation unit wide because
> of constexpr_call_table,
> however, during gimplify, the shared ctor could be modified. This patch
> fixes the issue by
Hi,
As reported in PR92926, constant ctor is shared translation unit wide because
of constexpr_call_table,
however, during gimplify, the shared ctor could be modified. This patch fixes
the issue by unsharing
it before modification in gimplify. A test is reduced from cppcoro library and
added.
On Tue, Oct 22, 2019 at 3:32 PM Jakub Jelinek wrote:
>
> On Mon, Oct 21, 2019 at 01:24:30PM +0200, Jakub Jelinek wrote:
> > So I wonder if for correctness I don't need to add:
> >
> > if (!use->iv->no_overflow
> > && !cand->iv->no_overflow
> > && !integer_pow2p (cstep))
> > retur
On Sat, Oct 19, 2019 at 2:27 PM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, the following patch attempts to address two issues.
> In remove_unused_ivs we first find the best iv_cand (we prefer primarily the
> same step, next same mode and lastly constant base) and only then call
> get
On Fri, Aug 23, 2019 at 4:27 PM Kewen.Lin wrote:
>
> Hi Bin
>
> on 2019/8/23 上午10:19, Bin.Cheng wrote:
> > On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> on 2019/8/22 下午1:46, Bin.Cheng wrote:
> >>> O
On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> on 2019/8/22 下午1:46, Bin.Cheng wrote:
> > On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> Thanks for your time!
> >>
> >> on
On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
>
> Hi Bin,
>
> Thanks for your time!
>
> on 2019/8/21 下午8:32, Bin.Cheng wrote:
> > On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
> >>
> >> Hi!
> >>
> >> Comparing to the previous ver
On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
>
> Hi!
>
> Comparing to the previous versions of implementation mainly based on the
> existing IV cands but zeroing the related group/use cost, this new one is
> based
> on Richard and Segher's suggestion introducing one doloop dedicated IV cand.
On Wed, Jun 19, 2019 at 7:47 PM Kewen.Lin wrote:
>
> Hi all,
>
> This is the following patch after
> https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00910.html
>
> Main steps:
> 1) Identify the doloop cmp type iv use and record its bind_cand (explain it
> later).
> 2) Set zero cost for pairs b
Hi,
This patch fixes PR91137 by finding base objects with walk_tree utility. Note
we specially return
integer_zero_node when a tree expression contains multiple base objects. This
works since the
special node is compared unequal to any real base object, thus skipped in
candidate selection.
Thi
On Fri, Jul 12, 2019 at 8:11 PM Richard Biener wrote:
>
> On Wed, 10 Jul 2019, Kewen.Lin wrote:
>
> > Hi all,
> >
> > I'd like to gentle ping the below patch:
> > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01225.html
> >
> > The previous version for more context/background:
> > https://gcc.gnu.
On Tue, May 21, 2019 at 1:50 PM Kewen.Lin wrote:
>
> on 2019/5/20 下午10:43, Jeff Law wrote:
> > On 5/20/19 4:24 AM, Segher Boessenkool wrote:
> >> Let me try to answer a bit here...
> >>
> >> On Mon, May 20, 2019 at 11:28:26AM +0200, Richard Biener wrote:
> >>> On Thu, 16 May 2019, li...@linux.ibm.
e.
Thanks,
bin
>
> Bill
>
>
> On 5/16/19 6:37 AM, Richard Biener wrote:
> > On Wed, May 15, 2019 at 6:30 AM bin.cheng
> > wrote:
> >> Hi,
> >> As noted in PR57534 comment #33, SLSR currently doesn't strength reduce
> >> memory
On Wed, May 15, 2019 at 5:51 PM Kewen.Lin wrote:
>
> on 2019/5/15 下午4:50, Bin.Cheng wrote:
> > On Wed, May 15, 2019 at 4:38 PM Kewen.Lin wrote:
> >>
> >> on 2019/5/15 上午10:11, Kewen.Lin wrote:
> >>>
> >>> on 2019/5/14 下午3:18, Richard Biener
On Wed, May 15, 2019 at 4:38 PM Kewen.Lin wrote:
>
> on 2019/5/15 上午10:11, Kewen.Lin wrote:
> >
> > on 2019/5/14 下午3:18, Richard Biener wrote:
> >> Hum. The function is somewhat of a hack, trying to produce
> >> "reasonable" DECL_RTL, exposing it in expr.[ch] with this
> >> name is eventually mis
On Wed, May 15, 2019 at 1:20 PM Kewen.Lin wrote:
>
> on 2019/5/15 上午11:34, Kewen.Lin wrote:
> >
> > on 2019/5/15 上午10:40, Bin.Cheng wrote:
> >> I wonder if you can factor out generic part into GIMPLE and leave
> >> target hook as specific as possible?
> &
Hi,
I noticed that cand_chain (first_interp/next_interp) is not maintained correctly
in slsr_process_copy/slsr_process_cast (now slsr_process_copycast). This one
fixes the issue, as well as records the "first" cand in stmt_cand_map.
Hi Bill, is this correct or I misunderstood the code? Bootstrap
Hi,
I noticed that slsr_process_copy and slsr_process_cast are almost identical
and called only once. This patch refactor the two functions into one.
For copies, it also passes lhs' type to creation of new cand assuming that
lhs, rhs and base_cand have the same/compatible type. I will keep an eye
Hi,
As noted in PR57534 comment #33, SLSR currently doesn't strength reduce memory
references in reported cases, which conflicts with its comment at the beginning
of file.
The main reason is in functions slsr_process_ref and restructure_reference which
rejects MEM_REF by handled_compoenent_p in th
I wonder if you can factor out generic part into GIMPLE and leave
target hook as specific as possible?
On Tue, May 14, 2019 at 11:10 AM wrote:
>
> From: Kewen Lin
>
> Previous version link for background:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>
> This hook is to predict whet
Hi,
While working on other PR, I noticed that we can save lots of if-then-else in
accessing
cand_vec by placing an additional NULL element at front of it.
Bootstrap and test on x86_64. Is it OK?
Thanks,
bin
2019-05-13 Bin Cheng
* gimple-ssa-strength-reduction.c (lookup_cand): Adjus
On Thu, May 9, 2019 at 5:31 AM Jeff Law wrote:
>
> On 5/8/19 6:28 AM, Richard Biener wrote:
> > On Wed, May 8, 2019 at 12:09 PM JunMa wrote:
> >>
> >> Hi
> >>
> >> As PR90106 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106),
> >> when gcc meets builtin function call like:
> >>
> >>y = sqr
On Mon, May 6, 2019 at 6:11 PM Richard Biener
wrote:
>
> On Sun, May 5, 2019 at 8:03 AM bin.cheng wrote:
> >
> > > --
> > > Sender:Jakub Jelinek
> > > Sent At:2019 Apr. 17 (Wed.) 19:27
> &
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
> >&g
low by introducing
> scaling bound
>
>
> On Sat, Apr 27, 2019 at 6:13 AM bin.cheng wrote:
> >
> > > Hi,
> >
> > This is the draft patch avoiding scaling cost overflow by introducing a
> > scaling bound
> > in IVOPTs. For now the bound is 20, and scaling
ed, Apr 17, 2019 at 07:14:05PM +0800, Bin.Cheng wrote:
> > > As
> > > #define INFTY 1000
> > > what is the reason to keep the previous condition as well?
> > > I mean, if cost1.cost == INFTY or cost2.cost == INFTY,
> > > cost1.cost + cost2.cost >=
1 - 100 of 919 matches
Mail list logo
