On Sat, Dec 20, 2014 at 8:18 PM, Eric Botcazou wrote:
>> As described both in the PR and patch comments, this patch fixes PR62151 by
>> setting right value to ELIM_I0/ELIM_I1 when distributing REG_DEAD notes from
>> i0/i1. It is said that distribute_notes had caused many bugs in the past.
>> I th
On Mon, Dec 22, 2014 at 3:54 PM, Bin.Cheng wrote:
> On Sat, Dec 20, 2014 at 8:18 PM, Eric Botcazou wrote:
>>> As described both in the PR and patch comments, this patch fixes PR62151 by
>>> setting right value to ELIM_I0/ELIM_I1 when distributing REG_DEAD notes from
>&g
On Wed, Dec 24, 2014 at 4:35 PM, zhangjian wrote:
> Hi, guys
>
> I encounter a gcc failure when I build mysql on opensuse[1]
> 5.6.17/storage/perfschema/pfs_account.cc:320:1: error: could not split insn
> [ 1245s] }
> [ 1245s] ^
> [ 1245s] (insn 482 1770 1461 (parallel [
> [ 1245s] (
On Sun, Jan 4, 2015 at 6:55 AM, Andrew Pinski wrote:
> On Mon, Nov 24, 2014 at 1:32 PM, Jeff Law wrote:
>> On 11/22/14 21:20, Andrew Pinski wrote:
>>>
>>> Hi,
>>>The problem here is here is that OBJCOPY is not being set to the
>>> newly built objcopy when compiling libgo. This patch adds
>>>
On Tue, Dec 16, 2014 at 6:37 PM, Bin.Cheng wrote:
> On Thu, Nov 13, 2014 at 1:54 PM, Bin Cheng wrote:
>> Hi,
>> As commented at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00684.html,
>> this is a simple patch enabling neon memset inlining on
>> cortex-a53
On Mon, Jan 5, 2015 at 3:44 PM, Kito Cheng wrote:
> Hi Vladimir:
> This patch has a discusses with you in May 2014, this patch is about
> the caller-save register store and restore instruction generation, the
> current LRA implementation will miss caller-save store/restore
> instruction if need
On Tue, Jan 6, 2015 at 7:36 AM, Vladimir Makarov wrote:
>
> On 2015-01-05 12:31 PM, Jeff Law wrote:
>>
>> On 01/05/15 00:44, Kito Cheng wrote:
>>>
>>> Hi Vladimir:
>>>This patch has a discusses with you in May 2014, this patch is about
>>> the caller-save register store and restore instruction
On Wed, Jan 7, 2015 at 4:03 PM, Kito Cheng wrote:
> Hi Jeff:
>
> It's updated patch,bootstrapped and run regression tested on arm-eabi,
> arm-none-linux-uclibcgnueabi, x86_64-unknown-linux-gnu and nds32le-elf
> without introducing regression.
>
> Thanks for your review :)
>
> 2015-01-07 Kito Chen
nce it introduces conflict option failures when testing against
specific processor, e.g. testing against Cortex-M profile processors.
Thanks,
bin
>
> On Wed, Jan 7, 2015 at 4:50 PM, Bin.Cheng wrote:
>> On Wed, Jan 7, 2015 at 4:03 PM, Kito Cheng wrote:
>>> Hi Jeff:
>>
On Fri, Jan 9, 2015 at 6:03 AM, Jeff Law wrote:
> On 01/08/15 08:58, Kito Cheng wrote:
>>
>> Hi Jeff:
>>
>> After discussion with Bin, he prefer just use
>> gcc.c-torture/execute/scal-to-vec1.c
>> instead of introduce new one, do you have any further comment on this
>> patch?
>
> Ah, if there's an
On Thu, May 23, 2013 at 4:29 PM, Richard Biener wrote:
>
> This is another case of ADDR_EXPRs not comparing equal from
> operand_equal_p if they contain volatile field references.
> The issue is that we should compare the FIELD_DECLs with
> retaining OEP_CONSTANT_ADDRESS_OF (or maybe not set TREE_
On Sat, Sep 6, 2014 at 3:33 AM, Evandro Menezes wrote:
> Bin,
>
> This is perhaps a plus for Aarch64 as well. Is there any plan to add a
> 64-bit version of this patch or should a bug be open for this?
Hi Evandro,
Yes, AARCH64 may want this too. I think Ramana/Marcus should have the
answer/plan
On Tue, Sep 9, 2014 at 6:49 PM, Richard Earnshaw wrote:
> On 04/09/14 07:08, Bin Cheng wrote:
>> @@ -1872,7 +1892,9 @@ const struct tune_params arm_cortex_a53_tune =
>>{true, true}, /* Prefer non short
>> circuit. */
>>&arm_default_vec_cost,
On Wed, Sep 10, 2014 at 4:57 PM, Kyrill Tkachov wrote:
>
> On 10/09/14 09:40, Christophe Lyon wrote:
>>
>> Hi,
>
> Hi Christophe,
>
>>
>> On 9 September 2014 13:02, Ramana Radhakrishnan
>> wrote:
>>>
>>> On Tue, Aug 19, 2014 at 4:22 PM, Kyrill Tkachov
>>> wrote:
Hi all,
In th
On Wed, Sep 10, 2014 at 6:21 PM, Bin.Cheng wrote:
> On Wed, Sep 10, 2014 at 4:57 PM, Kyrill Tkachov
> wrote:
>>
>> On 10/09/14 09:40, Christophe Lyon wrote:
>>>
>>> Hi,
>>
>> Hi Christophe,
>>
>>>
>>> On 9 September 2014 1
On Fri, Sep 12, 2014 at 4:01 AM, Jeff Law wrote:
> On 09/11/14 13:01, Segher Boessenkool wrote:
>>
>> Ping?
>
> Not forgotten. Still waiting to hear back from Bin on my recommendation
> that we drop the bogus note on the floor and avoid combining pseudos with
> multiple sets like that.
Sorry tha
On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo wrote:
> On Mon, 2013-06-17 at 10:41 +0200, Eric Botcazou wrote:
>> > My mistake. It's because arm_legitimize_address cannot re-factor "[r105 +
>> > r165*4 + (-2064)]" into "rx = r105 + (-2064); [rx + r165*4]". Do you
>> > suggest that this kind of trans
On Tue, Jun 18, 2013 at 10:02 PM, Oleg Endo wrote:
> On Tue, 2013-06-18 at 18:09 +0800, Bin.Cheng wrote:
>> On Tue, Jun 18, 2013 at 3:52 AM, Oleg Endo wrote:
>> >
>> > My observation is, that legitimizing addressing modes in the backend by
>> > looking at one
Ping this patch, http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01057.html
Thanks.
bin
Hi,
Function output_move_neon now generates vld1.64 for memory ref like "dx <-
[r1:SI]", this is bogus because it requires at least 64-bit alignment for
32-bit aligned memory ref. It works now because GCC doesn't generate such
insns in the first place, but things are going to change if memset/memc
Hi,
This patch expands small memset calls into direct memory set instructions by
introducing "setmemsi" pattern. For processors without NEON support, it
expands memset using general store instruction. For example, strd for
4-bytes aligned addresses. For processors with NEON support, it expands
m
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, April 25, 2014 4:53 AM
> To: Bin.Cheng
> Cc: Bin Cheng; gcc-patches List
> Subject: Re: [PATCH GCC]Fix pr60363 by adding backtraced value of phi arg
> along jump threading path
&
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, May 01, 2014 10:03 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> output_move_neon explicitly
>
> On 29/04/14 04:02, bin.cheng
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Monday, May 05, 2014 3:21 PM
> To: Richard Earnshaw
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH ARM] Improve ARM memset inl
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:
>>>
>>> Hi,
>>> I previously committed two patches lowering complex address expression for
>>> IVOPT
On Tue, May 6, 2014 at 6:44 PM, Richard Biener
wrote:
> On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote:
>> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
>> wrote:
>> Hi,
>> I split the patch into two and updated the test case.
>> The patches pass bootstr
On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng wrote:
> On Tue, May 6, 2014 at 6:44 PM, Richard Biener
> wrote:
>> On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote:
>>> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
>>> wrote:
>
>>> Hi,
>>> I
Ping.
Thanks,
bin
On Tue, May 6, 2014 at 12:59 PM, bin.cheng wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of bin.cheng
>> Sent: Monday, May 05, 2014 3:21 PM
>> To:
On Tue, May 13, 2014 at 4:59 PM, Richard Biener
wrote:
> On Sun, May 11, 2014 at 2:49 PM, Bin.Cheng wrote:
>> On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng wrote:
>>> On Tue, May 6, 2014 at 6:44 PM, Richard Biener
>>> wrote:
>>>> On Tue, May 6, 2014 at 10:39
Hi,
Targets like ARM and AARCH64 support double-word load store instructions,
and these instructions are generally faster than the corresponding two
load/stores. GCC currently uses peephole2 to merge paired load/store into
one single instruction which has a disadvantage. It can only handle simple
On Fri, May 16, 2014 at 12:57 AM, Steven Bosscher wrote:
> On Thu, May 15, 2014 at 9:26 AM, bin.cheng wrote:
>> Hi,
>> Targets like ARM and AARCH64 support double-word load store instructions,
>> and these instructions are generally faster than the corresponding two
>>
On Fri, May 16, 2014 at 1:13 AM, Jeff Law wrote:
> On 05/15/14 10:51, Mike Stump wrote:
>>
>> On May 15, 2014, at 12:26 AM, bin.cheng wrote:
>>>
>>> Here comes up with a new GCC pass looking through each basic block
>>> and merging paired load store ev
On Fri, May 16, 2014 at 12:51 AM, Mike Stump wrote:
> On May 15, 2014, at 12:26 AM, bin.cheng wrote:
>> Here comes up with a new GCC pass looking through each basic block and
>> merging paired load store even they are not adjacent to each other.
>
> So I have a target th
On Thu, May 15, 2014 at 6:31 PM, Oleg Endo wrote:
> Hi,
>
> On 15 May 2014, at 09:26, "bin.cheng" wrote:
>
>> Hi,
>> Targets like ARM and AARCH64 support double-word load store instructions,
>> and these instructions are generally faster than the correspo
On Sat, May 17, 2014 at 12:52 AM, Mike Stump wrote:
> On May 16, 2014, at 3:07 AM, Bin.Cheng wrote:
>>
>>> I don't see how regrename will help resolve [base+offset] false
>>> dependencies. Can you explain? I'd expect effects from
>>> hardreg-cop
On Sat, May 17, 2014 at 12:32 AM, Jeff Law wrote:
> On 05/16/14 04:07, Bin.Cheng wrote:
>
>> Yes, I think this one does have a good reason. The target independent
>> pass just makes sure that two consecutive memory access instructions
>> are free of data-dependency with e
On Sat, May 17, 2014 at 12:18 AM, Jeff Law wrote:
> On 05/16/14 04:07, Bin.Cheng wrote:
>>
>> On Fri, May 16, 2014 at 1:13 AM, Jeff Law wrote:
>>>
>>> On 05/15/14 10:51, Mike Stump wrote:
>>>>
>>>>
>>>> On May 15, 2014, at 1
Ping^2
Thanks,
bin
On Mon, May 12, 2014 at 11:17 AM, Bin.Cheng wrote:
> Ping.
>
> Thanks,
> bin
>
> On Tue, May 6, 2014 at 12:59 PM, bin.cheng wrote:
>>
>>
>> Precisely, I configured gcc with options "--with-arch=armv7-a
>> --with-cpu|--wi
On Tue, May 20, 2014 at 1:30 AM, Jeff Law wrote:
> On 05/19/14 00:38, Bin.Cheng wrote:
>>
>> On Sat, May 17, 2014 at 12:32 AM, Jeff Law wrote:
>>>
>>> On 05/16/14 04:07, Bin.Cheng wrote:
>>>
>>>
>>>
>>> But can't you go
On Tue, May 20, 2014 at 5:02 AM, Mike Stump wrote:
> On May 19, 2014, at 10:30 AM, Jeff Law wrote:
>>> Yes, I think it's more than upsizing the mode. There is another
>>> example from one of x86's candidate peephole patch at
>>> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00467.html
>>>
>>> Th
Hi,
I was surprised that GCC didn't support addressing modes like
[REG+OFF]/[REG_REG] for instructions ldr/str in vectorization scenarios.
The generated assembly is bad since all address expressions have to be
computed outside of memory reference. The root cause is because aarch64
effectively reje
Missing patch.
On Wed, May 28, 2014 at 3:02 PM, bin.cheng wrote:
> Hi,
> I was surprised that GCC didn't support addressing modes like
> [REG+OFF]/[REG_REG] for instructions ldr/str in vectorization scenarios.
> The generated assembly is bad since all address expressions have
Ping^3
> -Original Message-
> From: Bin.Cheng [mailto:amker.ch...@gmail.com]
> Sent: Monday, May 19, 2014 2:40 PM
> To: Bin Cheng
> Cc: Richard Earnshaw; gcc-patches List
> Subject: Re: [PATCH ARM] Improve ARM memset inlining
>
> Ping^2
>
> Thanks,
> bi
Hi Richard,
Does this have to wait for stage 1? Or I will try to work out a full
patch with loop recreating issue fixed.
On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener wrote:
>
> This allows cfgcleanup to remove some of the extra CFG that exists
> just for loop analysis passes convenience (those
On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener wrote:
> On Wed, 19 Feb 2014, Bin.Cheng wrote:
>
>> Hi Richard,
>> Does this have to wait for stage 1? Or I will try to work out a full
>> patch with loop recreating issue fixed.
>
> If it is a regression and there is
Hi,
The case is an execution case, while the main function doesn't return 0.
Committed as obvious.
Thanks,
bin
gcc/testsuite/ChangeLog
2014-02-20 Bin Cheng
* gcc.dg/tree-prof/crossmodule-indircall-1.c: Return 0
for execution test case.
And 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, February 20, 2014 6:42 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH GCC]Fix obvious bogus
On Thu, Feb 20, 2014 at 10:51 PM, Richard Biener wrote:
>
> The following fixes an ICE I got when building libjava with a local
> patch. This causes us to substitute &MEM[&a, 5] into MEM[_3, 0]
> to MEM[&MEM[&a, 5], 0] and then asking stmt_ends_bb_p which doesn't
> expect such bogus MEM_REFs. Th
Hi,
This patch is to fix regression reported in PR60280 by removing forward loop
headers/latches in cfg cleanup if possible. Several tests are broken by
this change since cfg cleanup is shared by all optimizers. Some tests has
already been fixed by recent patches, I went through and fixed the oth
reheaders and latches
>
> On Tue, Feb 25, 2014 at 6:12 AM, bin.cheng wrote:
> > Hi,
> > This patch is to fix regression reported in PR60280 by removing
> > forward loop headers/latches in cfg cleanup if possible. Several
> > tests are broken by this change since cfg clean
Thanks for reporting this, I will look into it.
Thanks,
bin
On Fri, Feb 28, 2014 at 8:52 AM, H.J. Lu wrote:
> On Mon, Feb 24, 2014 at 9:12 PM, bin.cheng wrote:
>> Hi,
>> This patch is to fix regression reported in PR60280 by removing forward loop
>> headers/latches in cf
Sorry, I didn't test it against logical_op_short_circuit target. I
will look into this PR.
Thanks,
bin
On Fri, Feb 28, 2014 at 9:34 AM, Hans-Peter Nilsson wrote:
> On Tue, 25 Feb 2014, bin.cheng wrote:
>
>> Hi,
>> This patch is to fix regression reported in PR60280 b
t;> On Fri, Feb 28, 2014 at 1:52 AM, H.J. Lu wrote:
>>>>>>> On Mon, Feb 24, 2014 at 9:12 PM, bin.cheng wrote:
>>>>>>>> Hi,
>>>>>>>> This patch is to fix regression reported in PR60280 by removing
>>>>>>>&
On Fri, Jul 4, 2014 at 1:17 PM, Bin Cheng wrote:
>
>
>
> Hi Ramana,
> This is the rebased patch, there is no conflict against latest trunk. I am
> still doing some tests. Is it OK if tests are fine?
> Also, it depends on patch at
> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html, I w
On Tue, Jul 8, 2014 at 2:50 PM, Jan Hubicka wrote:
>> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
>> >We propagate types from places we know instances are created across pointers
>> >passed to functions. Once non-POD type is created at a given memory
>> >location,
>> >one can not change its type
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng
Date: Thu, Jul 17, 2014 at 10:07 AM
Subject: [PATCH 1/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
This is a series of three patches improving induction variab
Forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng
Date: Thu, Jul 17, 2014 at 10:09 AM
Subject: [PATCH 3/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
Function iv_elimination_compare_lt is used to eliminate inducti
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng
Date: Thu, Jul 17, 2014 at 10:09 AM
Subject: [PATCH 3/3]Improve induction variable elimination
To: gcc-patches@gcc.gnu.org
Hi,
Function iv_elimination_compare_lt is used to eliminate ind
On Fri, Jul 25, 2014 at 1:27 PM, Richard Biener
wrote:
> On Thu, Jul 17, 2014 at 11:07 AM, Bin Cheng wrote:
>> Hi,
>> This is a series of three patches improving induction variable elimination.
>> Currently GCC only eliminates iv for very specific case when the loop's
>> latch could run zero time
On Fri, Jul 25, 2014 at 1:35 PM, Richard Biener
wrote:
> On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng wrote:
>> Hi,
>> As quoted from the function difference_cannot_overflow_p,
>>
>> /* TODO: deeper inspection may be necessary to prove the equality. */
>> switch (code)
>> {
>> case PL
On Mon, Aug 4, 2014 at 2:28 PM, Zhenqiang Chen wrote:
> Hi,
>
> For some TARGET, like ARM THUMB1, the offset in load/store should be nature
> aligned. But in function get_address_cost, when computing max_offset, it
> only tries byte-aligned offsets:
>
> ((unsigned HOST_WIDE_INT) 1 << i) - 1
>
>
On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
wrote:
> On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng wrote:
>> Hi,
>> As quoted from the function difference_cannot_overflow_p,
>>
>> /* TODO: deeper inspection may be necessary to prove the equality. */
>> switch (code)
>> {
>> case PL
Forgot the patch~
On Wed, Aug 6, 2014 at 10:32 AM, Bin.Cheng wrote:
> On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
> wrote:
>> On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng wrote:
>>> Hi,
>>> As quoted from the function difference_cannot_overflow_p,
>>>
Hi,
When I investigating PR60363 which is caused by previous patch for PR60280,
I found there is a latent bug in remove_forwarder_block_with_phi because GCC
doesn't update loop's latch information. Without this patch, cfgcleanup
facility will remove and rebuild the loop structure, resulting in los
Hi,
After control flow graph change made by
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01492.html, case
gcc.dg/tree-ssa/ssa-dom-thread-4.c is broken on logical_op_short_circuit
targets including cortex-m3/cortex-m0.
The regression reveals a missed opportunity in jump threading, which causes
a for
Hi,
Patch for PR60363 is sent at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00857.html , but it needs to
wait for stage 1. In the meanwhile this patch is to xfail the case for
logical_op_short_circuit targets. Is it ok?
Thanks,
bin
gcc/testsuite/ChangeLog
2014-04-01 Bin Cheng
PR t
Tue, Apr 1, 2014 at 7:42 AM, bin.cheng wrote:
> > Hi,
> > Patch for PR60363 is sent at
> > http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00857.html , but it needs
> > to wait for stage 1. In the meanwhile this patch is to xfail the case
> > for logical_op_short_circ
On Thu, Apr 10, 2014 at 8:18 AM, Wei Mi wrote:
> Hi,
>
> For the testcase 1.c
>
> #include
>
> double a[1000];
>
> __m128d foo1() {
> __m128d res;
> res = _mm_load_sd(&a[1]);
> res = _mm_loadh_pd(res, &a[2]);
> return res;
> }
>
> llvm will merge movsd/movhpd to movupd while gcc will not.
On Thu, Apr 17, 2014 at 1:30 PM, Jeff Law wrote:
> On 03/18/14 04:13, bin.cheng wrote:
>>
>> Hi,
>> After control flow graph change made by
>> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01492.html, case
>> gcc.dg/tree-ssa/ssa-dom-thread-4.c is broken on lo
On Tue, Apr 22, 2014 at 2:59 AM, Xinliang David Li wrote:
> Bin, when will the patch for the generic pass be available for review?
>
Hi,
The patch is still under working and reviewing. For arm we only need
to handle simple load/stores, so it may need to be extended to handle
generic memory access
On Mon, Jan 21, 2013 at 4:36 AM, Matthias Klose wrote:
> Am 18.01.2013 15:28, schrieb Ramana Radhakrishnan:
>> On 06/20/12 03:53, Yi-Hsiu Hsu wrote:
>>> marvell-pj4 is added to BE8_LINK_SPEC.
>>
>> Sorry about the time it's taken to finish this patch up. I seem to have
>> missed
>> this one in th
Sorry, I mis-sent this offline.
On Tue, Sep 4, 2012 at 11:00 PM, Bin.Cheng wrote:
>>>
>>> It's not ok (I btw fail to see the patch in this thread). The current
>>> way LOGICAL_OP_NON_SHORT_CIRCUIT is implemented/used should instead
>>&g
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 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
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
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 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
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
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
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
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
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
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
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
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 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:
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
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
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
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 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
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 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 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 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
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 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:
> >
> &
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 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 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)
801 - 900 of 919 matches
Mail list logo
