On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen wrote:
> A somewhat old "issue report" pointed me to the code generated for a 4-fold
> manually unrolled version of the following loop:
>
>> while (++len != len_limit) /* this is loop */
>> if (pb[l
On Fri, Jun 29, 2018 at 9:54 PM, Martin Liška wrote:
> On 06/22/2018 10:35 PM, Jeff Law wrote:
>> On 05/16/2018 05:53 AM, Martin Liška wrote:
>>> On 12/21/2017 10:13 AM, Martin Liška wrote:
On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
> Another thing is that the "/" in there is wrong, so
al optimizations?
I am not aware of one for unsigned integer, and I guess it won't be
introduced in the future either?
Thanks,
bin
>
>
>
> On 7/13/18 9:14 PM, Bin.Cheng wrote:
>> On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen
>> wrote:
>>> A somewhat old
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
--
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 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:
>
> > + 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
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
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
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
> > >
> > >
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,
> >>>
> >>
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 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,
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
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
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,
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 {
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,
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
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,
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
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,
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 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,
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
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
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
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 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 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
> > &
Ping^2
Thanks.
bin
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of bin.cheng
Sent: Thursday, August 08, 2013 4:51 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw
Subject: [PING][PATCH ARM]Extend thumb1_reorg to save more
Hi,
This patch refines scaled address expression on ARM. It supports
"base+index*scale" in arm_legitimate_address_outer_p. It also tries to
legitimize "base + index * scale + offset" with "reg <- base + offset; reg
+ index * scale" by introducing thumb2_legitimize_address. For now function
thu
Hi,
The attached patch disables rtl loop invariant when optimizing for code
size. Committed to ARM/Embedded-4_8-branch as r202067.
Thanks.
bin
2013-08-29 Zhenqiang Chen
* config/arm/arm.c (arm_option_override): Disable loop2_invariant
pass when optimize_size and ira-loop-pre
Hi,
The gimple-ssa-strength-reduction pass handles CAND_REFs in order to find
different MEM_REFs sharing common part in addressing expression. If such
MEM_REFs are found, the pass rewrites MEM_REFs, and produces more efficient
addressing expression during the RTL passes.
The pass analyzes address
Hi,
For now set_autoinc_for_original_candidates only searches auto-inc uses
before candidate's increment, causing pre-increment opportunities missed for
original candidates. This is a straightforward fix by searching after
candidate's increment too.
The patch also includes a test case to illustra
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, August 29, 2013 9:06 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Refine scaled address expression on ARM
>
> On 28/08/13 08:00, bin.cheng wrote:
> > Hi,
>
On Wed, Sep 4, 2013 at 5:20 PM, Richard Biener wrote:
>
> The patch below moves IVOPTs out of the GIMPLE loop pipeline more
> closer to RTL expansion. That's done for multiple reasons.
>
> First, the loop passes that at the moment preceede IVOPTs leave
> around IL that is in desparate need of bas
On Mon, Sep 9, 2013 at 10:01 AM, Bin.Cheng wrote:
> On Wed, Sep 4, 2013 at 5:20 PM, Richard Biener wrote:
>>
>> The patch below moves IVOPTs out of the GIMPLE loop pipeline more
>> closer to RTL expansion. That's done for multiple reasons.
>>
>> Fir
Thanks for reviewing, I will correct all stupid spelling problem in the next
version of patch.
On Mon, Sep 9, 2013 at 8:15 AM, Bill Schmidt
wrote:
>
>>>+ int (i * S).
>>>+ Otherwise, just return double int zero. */
>
> This is sufficient, since you are properly checking the next_interp
> c
On Tue, Sep 10, 2013 at 3:30 AM, Steven Bosscher wrote:
> On Mon, Sep 9, 2013 at 10:01 AM, Richard Biener wrote:
>>> >> First, the loop passes that at the moment preceede IVOPTs leave
>>> >> around IL that is in desparate need of basic re-optimization
>>> >> like CSE, constant propagation and DCE.
On Mon, Sep 9, 2013 at 11:35 PM, Bill Schmidt
wrote:
>
>> > I rely on size_binop to convert T2 into sizetype, because T2' may be in
>> > other kind of type. Otherwise there will be ssa_verify error later.
>>
>> OK, I see now. I had thought this was handled by fold_build2, but
>> apparently not
On Tue, Sep 10, 2013 at 9:30 PM, Bill Schmidt
wrote:
>
>
> On Tue, 2013-09-10 at 15:41 +0800, bin.cheng wrote:
>> On Mon, Sep 9, 2013 at 11:35 PM, Bill Schmidt
>> wrote:
>> >
>> >> > I rely on size_binop to convert T2 into sizetype, beca
Ping ^ 3
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of bin.cheng
Sent: Friday, August 23, 2013 3:23 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw
Subject: RE: [PING][PATCH ARM]Extend thumb1_reorg to save more comparison
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, September 12, 2013 11:24 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Extend thumb1_reorg to save more comparison
> instructions
>
> On 18/04/13 06:34, Bin Cheng wrote:
>
> Sorry for the delay,
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Thursday, September 12, 2013 2:13 PM
> To: 'Bill Schmidt'; Yufeng Zhang; Yufeng Zhang
> Cc: Richard Biener; GCC Patches
> Sub
> -Original Message-
> From: Dominique Dhumieres [mailto:domi...@lps.ens.fr]
> Sent: Wednesday, September 18, 2013 1:47 AM
> To: gcc-patches@gcc.gnu.org
> Cc: hjl.to...@gmail.com; Bin Cheng
> Subject: Re: [PATCH GCC]Catch more MEM_REFs sharing common
> addressing part in gimple strength r
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Monday, September 02, 2013 3:09 PM
> To: Richard Earnshaw
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH ARM]Refine scaled addr
Hi,
For now IVOPT constructs scaled address expression in the form of
"scaled*index" and checks whether backend supports it. The problem is the
address expression is invalid on ARM, causing scaled expression disabled in
IVOPT on ARM. This patch fixes the IVOPT part by constructing rtl address
expr
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, September 23, 2013 8:08 PM
> To: Bin Cheng
> Cc: GCC Patches
> Subject: Re: [PATCH]Construct canonical scaled address expression in IVOPT
>
> On Fri, Sep 20, 201
Hi,
This patch fix two minor bugs when computing offset in IVOPT.
1) Considering below example:
#define MAX 100
struct tag
{
int i;
int j;
}
struct tag arr[MAX]
int foo (int len)
{
int i = 0;
for (; i < len; i++)
{
access arr[i].j;
}
}
Without this patch, the offset computed by st
On Tue, Sep 24, 2013 at 6:12 PM, Richard Biener
wrote:
> On Tue, Sep 24, 2013 at 8:20 AM, bin.cheng wrote:
>>
>>
>>> -Original Message-
>
> Or even [reg*scale] (not sure about that). But yes, at least reg*scale +
> offset
> and reg*scale + reg.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, September 24, 2013 7:58 PM
> To: Bin.Cheng
> Cc: Bin Cheng; GCC Patches; Richard Earnshaw
> Subject: Re: [PATCH]Construct canonical scaled address expression in IVOPT
&
Sorry for missing the patch.
Thanks.
bin
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Thursday, September 26, 2013 8:05 PM
> To: 'Richard Biener'; Bin.Cheng
> Cc: G
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, September 24, 2013 6:31 PM
> To: Bin Cheng
> Cc: GCC Patches
> Subject: Re: [PATCH]Fix computation of offset in ivopt
>
> On Tue, Sep 24, 2013 at 11
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Friday, September 27, 2013 1:07 PM
> To: 'Richard Biener'
> Cc: GCC Patches
> Subject: RE: [PATCH]Fix
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, September 27, 2013 4:30 PM
> To: Bin Cheng
> Cc: GCC Patches
> Subject: Re: [PATCH]Fix computation of offset in ivopt
>
> On Fri, Sep 27, 2013 at 7:07 AM, bin.cheng w
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Oleg Endo
> Sent: Wednesday, September 25, 2013 1:41 AM
> To: Richard Biener
> Cc: Bin Cheng; GCC Patches
> Subject: Re: [PATCH]Fix computation of offset in ivopt
>
> >
>
>
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
wrote:
> On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng wrote:
>>
>>
>
> I don't think you need
>
> + /* Sign extend off if expr is in type which has lower precision
> + than HOST_WIDE_INT. */
>
On Wed, Oct 17, 2012 at 6:54 AM, Steven Bosscher wrote:
> On Tue, Oct 16, 2012 at 1:38 PM, Paolo Bonzini wrote:
Bottom line: This is a bug in df_kill_notes.
>>
>> Yep, and it could cause wrong code generation, couldn't it? Because the
>> new (reg:DI 72) is obviously not equal to (plus:DI (re
On Tue, Oct 30, 2012 at 8:23 AM, Lawrence Crowl wrote:
> On 10/29/12, Diego Novillo wrote:
>> On Oct 29, 2012 Diego Novillo wrote:
>> > Just to make sure. Testing on ppc should be fast, for example.
>>
>> And useless. Your patch does not touch ppc.
>
> I've fixed the #if 0 and the remaining su
Sorry that I don't understand tree type system well, so here are two
more questions, could you please explain little bit more? Thanks very
much.
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
wrote:
> On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng wrote:
>
> I don't think you
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
wrote:
> On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng wrote:
>>
>
> I don't think you need
>
> + /* Sign extend off if expr is in type which has lower precision
> + than HOST_WIDE_INT. */
> + if
/testsuite/ChangeLog
2013-10-17 Bin Cheng
* gcc.dg/tree-ssa/ivopts-outside-loop-use-1.c: New test.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, October 02, 2013 4:32 PM
> To: Bin.Cheng
> Cc: Bin Cheng; GCC Patche
Hi Richard,
Is the first patch OK? Since there is a patch depending on it.
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01931.html
Thanks.
bin
On Fri, Oct 18, 2013 at 7:18 PM, Richard Biener
wrote:
> On Thu, Oct 17, 2013 at 7:52 AM, bin.cheng wrote:
>> Hi,
>> As noted in pr
On Fri, Oct 18, 2013 at 7:18 PM, Richard Biener
wrote:
> On Thu, Oct 17, 2013 at 7:52 AM, bin.cheng wrote:
>> Hi,
>> As noted in previous messages, GCC forces offset to unsigned in middle end.
>> It also gets offset value and stores it in HOST_WIDE_INT then uses it in
>&g
On Mon, Oct 21, 2013 at 8:21 PM, Richard Biener
wrote:
> On Fri, Oct 18, 2013 at 5:48 PM, Bin.Cheng wrote:
>> Hi Richard,
>> Is the first patch OK? Since there is a patch depending on it.
>> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01931.html
>
> Yes.
I
Hi,
I noticed that IVOPT generates complex address expressions like below for iv
base.
&arr_base[0].y
&arr[0]
&MEM[p+o]
It's even worse for targets support auto-increment addressing mode because
IVOPT adjusts such base expression with +/- step, then creates below:
&a
Hi,
The IVOPT in GCC has a problem that it does not use cost of auto-increment
address expression in accounting, while it retreats to cost of address
expression if auto-increment addressing mode is unavailable.
For example, on ARM target:
1) the cost of "[reg]" (which is 6) is used for address exp
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, October 30, 2013 10:46 PM
> To: Bin Cheng
> Cc: GCC Patches
> Subject: Re: [PATCH GCC]Simplify address expression in IVOPT
>
> On Tue, Oct 29, 2013 at 10:18 AM, bi
On Mon, Nov 4, 2013 at 7:38 PM, Richard Biener
wrote:
> On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng wrote:
>> Hi,
>>
>> The IVOPT in GCC has a problem that it does not use cost of auto-increment
>> address expression in accounting, while it retreats to cost of ad
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Monday, November 04, 2013 4:35 PM
> To: 'Richard Biener'
> Cc: GCC Patches
> Subject: RE: [PATCH GCC]Simpl
On Tue, Nov 5, 2013 at 7:19 PM, Yufeng Zhang wrote:
> On 11/05/13 10:13, bin.cheng wrote:
>>
>> Index: gcc/tree-affine.c
>> ===
>> --- gcc/tree-affine.c (revision 204117)
>> +++ gcc/tree-affine
On Wed, Feb 10, 2016 at 1:27 PM, Richard Biener
wrote:
>
> On Wed, Feb 10, 2016 at 12:34 PM, Bin Cheng wrote:
> > Hi,
> > This is another way to fix PR68021, and I think it's the least intrusive
> > way. The issue is triggered in a special case in which cand is a original
> > biv, and use deno
On Thu, Feb 11, 2016 at 7:14 AM, Jeff Law wrote:
> On 02/09/2016 04:08 AM, Bin Cheng wrote:
>>
>> Hi,
>> When counting cost for loop inv, GCC checks if a loop inv can be
>> propagated into its use site (a memory reference). If it cannot be
>> propagated, we increase its cost so that it's expensiv
On Fri, Feb 19, 2016 at 10:24 PM, Jeff Law wrote:
> On 02/16/2016 11:43 AM, Bin Cheng wrote:
>>
>>
>> From: Jeff Law
>> Sent: 11 February 2016 23:26
>> To: Bin.Cheng
>> Cc: Bin Cheng; gcc-patches@gcc.gnu.org; nd
On Fri, Feb 19, 2016 at 10:24 PM, Jeff Law wrote:
> On 02/16/2016 11:43 AM, Bin Cheng wrote:
>>
>>
>> From: Jeff Law
>> Sent: 11 February 2016 23:26
>> To: Bin.Cheng
>> Cc: Bin Cheng; gcc-patches@gcc.gnu.org; nd
On Thu, Feb 25, 2016 at 6:39 AM, Jeff Law wrote:
> On 02/22/2016 02:22 AM, Bin.Cheng wrote:
>
>>> My only question is why didn't you use FOR_EACH_SUBRTX_VRA from
>>> rtl-iter.h
>>> to walk the RTX expressions in collect_address_parts and
>>> canon
On Thu, Feb 25, 2016 at 8:47 AM, Bin.Cheng wrote:
> On Thu, Feb 25, 2016 at 6:39 AM, Jeff Law wrote:
>> On 02/22/2016 02:22 AM, Bin.Cheng wrote:
>>
>>>> My only question is why didn't you use FOR_EACH_SUBRTX_VRA from
>>>> rtl-iter.h
>>>>
On Fri, Mar 4, 2016 at 11:57 AM, Richard Biener
wrote:
> On Fri, Mar 4, 2016 at 12:07 PM, Bin Cheng wrote:
>> Hi,
>> A address canonicalization interface was introduced by my original patch to
>> PR69052. The interface sorts sub-parts in an address expression based on
>> precedences defined by
Ping^2
Thanks,
bin
On Fri, Nov 22, 2013 at 3:32 PM, bin.cheng wrote:
> PING.
> Hi, there is a patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01353.html which slipped away.
>
> Thanks,
> bin
>
>
>
--
Best Regards.
Hi,
This patch back ports revision 200103 from mainline to
ARM/Embedded-4_8-branch. It is tested on arm cortex-m3 and no regressions.
Thanks,
binIndex: gcc/tree-ssa-uncprop.c
===
--- gcc/tree-ssa-uncprop.c (revision 205471)
+++
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw wrote:
> On 18/09/13 10:15, bin.cheng wrote:
>>
>>
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>> ow...@gcc.gnu.org] On Behalf Of bin.cheng
>>&
On Thu, Nov 28, 2013 at 8:06 PM, Bin.Cheng wrote:
> On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw wrote:
>> On 18/09/13 10:15, bin.cheng wrote:
>>>
>>>
>>>> -Original Message-
>>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patc
On Fri, Nov 29, 2013 at 6:44 PM, Richard Biener
wrote:
> On Fri, Nov 29, 2013 at 8:52 AM, Bin.Cheng wrote:
>> On Thu, Nov 28, 2013 at 8:06 PM, Bin.Cheng wrote:
>>> On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw wrote:
>>>> On 18/09/13 10:15, bin.cheng wrote:
&g
On Sat, Nov 30, 2013 at 12:34 AM, Richard Earnshaw wrote:
> On 29/11/13 11:46, Yufeng Zhang wrote:
>> On 11/29/13 07:52, Bin.Cheng wrote:
>>> After thinking twice, I some kind of think we should not re-associate
>>> addresses during expanding, because of lacking of cont
On Sat, Nov 30, 2013 at 12:34 AM, Richard Earnshaw wrote:
> On 29/11/13 11:46, Yufeng Zhang wrote:
>> On 11/29/13 07:52, Bin.Cheng wrote:
>>> After thinking twice, I some kind of think we should not re-associate
>>> addresses during expanding, because of lacking of cont
On Thu, Dec 5, 2013 at 6:57 AM, Joseph S. Myers wrote:
> Index: c-family/c-common.c
> ===
> --- c-family/c-common.c (revision 205668)
> +++ c-family/c-common.c (working copy)
> @@ -4921,14 +4921,17 @@ c_common_get_alias_set (tree t)
On Fri, Dec 6, 2013 at 2:10 PM, Jeff Law wrote:
> On 11/26/13 03:52, Bin.Cheng wrote:
>>
>> On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law wrote:
>>>
>>> On 11/25/13 02:11, Bin.Cheng wrote:
>>>>
>>>>
>>>>
>>>> Slightly
Hi,
Entry pr41488 shows a case in which induction variable can't be recognized
or coalesced. As noted in the bug entry, one possible fix is to teach PRE
not to do some specific transformation. However, it's in nature a scalar
evolution issue. Considering below snippet:
# i_17 = PHI
# _20
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
wrote:
> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
>> On 11/25/13 02:22, bin.cheng wrote:
>>
>> Unless there's a PR for this problem, I think this needs to wait.
>
> I agree. Btw, please split the patch.
Ye
On Fri, Dec 6, 2013 at 7:20 PM, Richard Biener
wrote:
> On Fri, Dec 6, 2013 at 11:40 AM, Bin.Cheng wrote:
>> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
>> wrote:
>>> On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law wrote:
>>>> On 11/25/13 02:22, bin.cheng wrot
On Sat, Dec 7, 2013 at 3:20 AM, Jeff Law wrote:
> On 12/06/13 03:29, bin.cheng wrote:
>>
>> Hi,
>> Entry pr41488 shows a case in which induction variable can't be recognized
>> or coalesced. As noted in the bug entry, one possible fix is to teach PRE
>>
On Mon, Dec 9, 2013 at 12:00 PM, Jeff Law wrote:
> On 12/06/13 19:44, Bin.Cheng wrote:
>>>
>>> Right. Based on reading the archives, it looks like this stuff is/was
>>> generated by PRE. I also suspect jump threading can create them. There
>>> was
>&g
> -Original Message-
> From: Bin.Cheng [mailto:amker.ch...@gmail.com]
> Sent: Monday, December 09, 2013 1:15 PM
> To: Jeff Law
> Cc: Bin Cheng; gcc-patches List
> Subject: Re: [PATCH PR41488]Recognize more induction variables by
> simplifying PEELED chrec in scalar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, December 10, 2013 6:31 AM
> To: Bin.Cheng
> Cc: gcc-patches List; Richard Biener; Zdenek Dvorak
> Subject: Re: [Ping]Two
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test on current upstream.
On Wed, Dec 11, 2013 at 4:31 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 6:46 PM, bin.cheng wrote:
>>
>>>
>> Hi,
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test on current upstream.
On Wed, Dec 11, 2013 at 4:17 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 11:59:16PM -0700, Jeff Law wrote:
>> On 12/10/13 23:35, Bin.Cheng wrote:
>> >I know little about GC, so when ggc_collect may be called (between two
>> >passes)? If so, I have to call fr
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, December 11, 2013 6:04 PM
> To: Jakub Jelinek
> Cc: Bin.Cheng; Jeff Law; Bin Cheng; gcc-patches List
> Subject: Re: [PATCH PR41488]Recognize more induction variables by
&g
1 - 100 of 919 matches
Mail list logo
