Please ignore this one, I will further refine it. Sorry for disturbing!
Thanks,
bin
On Tue, Dec 16, 2014 at 4:42 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Dec 11, 2014 at 8:08 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 11, 2014 at 10:56 AM, Bin.Cheng amker.ch
On Wed, Dec 10, 2014 at 9:47 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Dec 5, 2014 at 1:15 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Though PR62178 is hidden by recent cost change in aarch64 backend, the ivopt
issue still exists.
Current candidate selecting algorithm
On Thu, Dec 11, 2014 at 5:56 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Dec 10, 2014 at 9:47 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Dec 5, 2014 at 1:15 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Though PR62178 is hidden by recent cost change in aarch64 backend
On Wed, Dec 10, 2014 at 10:18 AM, Andrew Pinski pins...@gmail.com wrote:
Hi,
As mentioned in
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00609.html, the
load/store pair peepholes currently accept volatile mem which can
cause wrong code as the architecture does not define which part of the
On Wed, Dec 10, 2014 at 6:58 AM, Jeff Law l...@redhat.com wrote:
On 12/05/14 05:15, Bin Cheng wrote:
Hi,
Though PR62178 is hidden by recent cost change in aarch64 backend, the
ivopt
issue still exists.
Current candidate selecting algorithm tends to select fewer candidates
given
below
On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski pins...@gmail.com wrote:
On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski pins...@gmail.com wrote:
On Sat, Dec 6, 2014 at 5:54 PM, Andrew Pinski pins...@gmail.com wrote:
On Fri, Dec 5, 2014 at 9:08 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com
On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski pins...@gmail.com wrote:
On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski pins...@gmail.com wrote:
On Sat, Dec 6, 2014 at 6:35 PM, Andrew Pinski pins...@gmail.com wrote:
On Sat
On Mon, Dec 8, 2014 at 11:26 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski pins...@gmail.com wrote:
On Sun, Dec 7, 2014 at 5:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Sun, Dec 7, 2014 at 6:24 PM, Andrew Pinski pins...@gmail.com wrote:
On Sat
On Mon, Dec 8, 2014 at 11:38 AM, Andrew Pinski pins...@gmail.com wrote:
On Sun, Dec 7, 2014 at 7:35 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Mon, Dec 8, 2014 at 11:26 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Mon, Dec 8, 2014 at 11:16 AM, Andrew Pinski pins...@gmail.com wrote:
On Sun
On Wed, Dec 3, 2014 at 1:54 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Tue, Dec 02, 2014 at 07:11:04PM -0600, Segher Boessenkool wrote:
Here is the testcase. I cannot actually test it on an m68k build, should
really do something about that (I build lots of cross compilers but
Ping^2
Thanks,
bin
On Tue, Nov 25, 2014 at 4:19 PM, Bin.Cheng amker.ch...@gmail.com wrote:
Ping. Anybody have a look?
Thanks,
bin
On Tue, Nov 18, 2014 at 4:34 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
This is the patch implementing ldp/stp optimization for aarch64. It
consists of two
On Mon, Nov 24, 2014 at 10:28 PM, James Greenhalgh
james.greenha...@arm.com wrote:
On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law l...@redhat.com wrote:
On 11/05/14 02:30, Bin.Cheng wrote:
Thanks very much for reviewing. I refined
Ping. Anybody have a look?
Thanks,
bin
On Tue, Nov 18, 2014 at 4:34 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
This is the patch implementing ldp/stp optimization for aarch64. It
consists of two parts. The first one is peephole part, which further
includes ldp/stp patterns (both peephole
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law l...@redhat.com wrote:
On 11/05/14 02:30, Bin.Cheng wrote:
[ ... ]
rfs_result's signature has changed, I think you need to pass in tmp
tmp2.
You'll need to make that trivial update for all the callers.
Can you make those changes and repost so
On Thu, Nov 13, 2014 at 2:33 PM, Yangfei (Felix) felix.y...@huawei.com 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/cortex-a57 in AArch32 mode.
Test on
On Thu, Nov 13, 2014 at 3:04 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
On Thu, Nov 13, 2014 at 2:33 PM, Yangfei (Felix) felix.y...@huawei.com
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 Thu, Nov 13, 2014 at 3:20 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
Just curious about this. Can we make sure that FPAdvSIMD are
always
enabled?
I am not sure I understand correct, do you mean enable options like
below default?
On Sat, Nov 1, 2014 at 4:29 AM, Jeff Law l...@redhat.com wrote:
On 09/30/14 03:22, Bin Cheng wrote:
2014-09-30 Bin Chengbin.ch...@arm.com
Mike Stumpmikest...@comcast.net
* timevar.def (TV_SCHED_FUSION): New time var.
* passes.def (pass_sched_fusion): New pass.
On Mon, Nov 3, 2014 at 6:11 AM, Andreas Tobler andreast-l...@fgznet.ch wrote:
Hello all,
this is a patch which brings support for arm*-*-freebsd* to trunk.
The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
armv6hf-*-freebsd*.
armv6 stands for ARM_ARCH == 6, arm stands for
Thanks for giving it a try.
On Fri, Oct 31, 2014 at 3:43 AM, Jeff Law l...@redhat.com wrote:
On 10/10/14 21:32, Bin.Cheng wrote:
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
Thanks to both of you for your answers
On Sat, Oct 11, 2014 at 5:13 AM, Jeff Law l...@redhat.com wrote:
On 09/30/14 03:22, Bin Cheng wrote:
Hi,
many load/store pairs as my old patch. Then I decided to take one step
forward to introduce a generic instruction fusion infrastructure in GCC,
because in essence, load/store pair is
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
On Sat, Oct 11, 2014 at 7:10 AM, Mike Stump mikest...@comcast.net wrote:
[ I'll give the state of the code that I finished with, Bin's answers should
be similar to mine, but, if
Ping. Any review comments?
Thanks,
bin
On Wed, Oct 1, 2014 at 6:31 AM, Sebastian Pop seb...@gmail.com wrote:
Bin Cheng wrote:
Hi,
As analyzed in PR62178, IVOPT can't find the optimal iv set for that case.
The problem with current heuristic algorithm is it only replaces candidate
with ones
On Wed, Oct 8, 2014 at 1:28 PM, Jeff Law l...@redhat.com wrote:
On 10/06/14 19:31, Bin.Cheng wrote:
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump mikest...@comcast.net wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com
wrote:
On Mon, Oct 6, 2014 at 11:57 AM
On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump mikest...@comcast.net wrote:
On Sep 30, 2014, at 2:22 AM, Bin Cheng bin.ch...@arm.com wrote:
Then I decided to take one step forward to introduce a generic
instruction fusion infrastructure in GCC, because in essence, load/store
pair is nothing
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump mikest...@comcast.net wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng amker.ch...@gmail.com wrote:
How many merging opportunities does sched2 undo again? ISTR it
has
On Fri, Sep 12, 2014 at 4:01 AM, Jeff Law l...@redhat.com 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.
On Wed, Sep 10, 2014 at 6:21 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Sep 10, 2014 at 4:57 PM, Kyrill Tkachov kyrylo.tkac...@arm.com
wrote:
On 10/09/14 09:40, Christophe Lyon wrote:
Hi,
Hi Christophe,
On 9 September 2014 13:02, Ramana Radhakrishnan
ramana@googlemail.com
On Sat, Sep 6, 2014 at 3:33 AM, Evandro Menezes e.mene...@samsung.com 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
On Tue, Sep 9, 2014 at 6:49 PM, Richard Earnshaw rearn...@arm.com 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 kyrylo.tkac...@arm.com wrote:
On 10/09/14 09:40, Christophe Lyon wrote:
Hi,
Hi Christophe,
On 9 September 2014 13:02, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Tue, Aug 19, 2014 at 4:22 PM, Kyrill Tkachov
On Tue, Sep 2, 2014 at 9:40 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Tue, Sep 02, 2014 at 02:10:32PM +0200, Ulrich Weigand wrote:
In any case, this test in can_combine_p rejects a combination for *two*
different issues. One is the earlyclobber problem, which is what that
On Tue, Sep 2, 2014 at 1:50 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Mon, Sep 01, 2014 at 10:39:10AM -0600, Jeff Law wrote:
On 09/01/14 05:38, Segher Boessenkool wrote:
On Mon, Sep 01, 2014 at 11:36:07AM +0800, Bin.Cheng wrote:
In the testcase (and comment in the proposed
On Tue, Sep 2, 2014 at 11:40 AM, Jeff Law l...@redhat.com wrote:
On 08/31/14 22:18, Bin.Cheng wrote:
Note that i0..i4 need not be consecutive insns, so you'd have to walk the
chain from the location with the death note to the proposed death note
site.
If between those locations there's
On Tue, Sep 2, 2014 at 11:28 AM, Jeff Law l...@redhat.com wrote:
On 09/01/14 13:15, Segher Boessenkool wrote:
On Mon, Sep 01, 2014 at 10:41:43AM -0600, Jeff Law wrote:
On 08/31/14 06:18, Segher Boessenkool wrote:
On Fri, Aug 29, 2014 at 11:58:37PM -0600, Jeff Law wrote:
One could argue
On Sun, Aug 31, 2014 at 8:18 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Fri, Aug 29, 2014 at 11:58:37PM -0600, Jeff Law wrote:
One could argue that this mess is a result of trying to optimize a reg
that is set more than once.Though I guess that might be a bit of a
big
On Sat, Aug 30, 2014 at 1:58 PM, Jeff Law l...@redhat.com wrote:
On 08/27/14 23:04, Bin.Cheng wrote:
On Wed, Aug 27, 2014 at 6:34 PM, Richard Earnshaw rearn...@arm.com
wrote:
On 27/08/14 11:08, Bin Cheng wrote:
Hi
As reported in bug pr62151, combine pass may wrongly delete necessary
On Wed, Aug 27, 2014 at 4:23 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Aug 27, 2014 at 10:10 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As I analyzed in bug pr62178, current candidate selecting algorithm can't
find out the optimal solution in some scenarios. I am trying to
On Wed, Aug 27, 2014 at 6:34 PM, Richard Earnshaw rearn...@arm.com wrote:
On 27/08/14 11:08, Bin Cheng wrote:
Hi
As reported in bug pr62151, combine pass may wrongly delete necessary
instruction in function distribute_notes thus leaving register
uninitialized. This patch is to fix the issue
On Tue, Aug 26, 2014 at 4:46 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Aug 25, 2014 at 11:07 PM, Sebastian Pop seb...@gmail.com wrote:
Sebastian Pop wrote:
Richard Biener wrote:
I think it would be better to identify a set of features we rely on that
are not present in
On Thu, Aug 21, 2014 at 5:08 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Aug 21, 2014 at 10:28 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Canadian build of arm/aarch64 (and other targets) toolchains are broken
because of isl library check. There is below code in top level gcc
I think it's a issue in isl library check for (Canadian)
cross_compiling. Will send a patch soon.
Thanks,
bin
On Wed, Aug 20, 2014 at 1:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev gareevro...@gmail.com wrote:
Which configure options do you use
I suspect this causes arm/aarch64 native bootstrap failure with below messages.
aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic
.)
I can't access the build bot right now, so haven't tried other options
yet. The latest good I got build was against r213896.
Thanks,
bin
2014-08-20 9:28 GMT+06:00 Bin.Cheng amker.ch...@gmail.com:
I suspect this causes arm/aarch64 native bootstrap failure with below
messages.
aarch64-none
Hi,
PR62151 is about wrong code generated on x86_641, which starts from
one of my checkin. I did some investigation, now can confirm it's
another latent bug in combine pass as analyzed by comment#7 in the PR.
Here is a patch can fix the problem, as well as the code given in the
comment. It
On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang gang.chen.5...@gmail.com wrote:
On 08/18/2014 03:05 PM, Bin.Cheng wrote:
On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang gang.chen.5...@gmail.com wrote:
On 08/10/2014 04:15 PM, Chen Gang wrote:
On 08/10/2014 04:03 PM, Mike Stump wrote:
On Aug 9, 2014
On Thu, Aug 14, 2014 at 11:29 PM, Sebastian Pop seb...@gmail.com wrote:
Bin.Cheng wrote:
The overflow check can be improved by using deeper inspection to prove the
equality. This patch deals with that by making below two improvements:
a) Handles constant cases.
b) Uses affine
On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As quoted from the function difference_cannot_overflow_p,
/* TODO: deeper inspection may be necessary to prove the equality. */
On Thu, Aug 14, 2014 at 11:18 PM, Jason Merrill ja...@redhat.com wrote:
On 08/14/2014 04:31 AM, Bin Cheng wrote:
g++.dg/ext/arm-fp16/fp16-mangle-1.C is failed because GCC now sets
DECL_COMDAT on template instantiations if flag_implicit_templates is in
effect. Then DECL_WEAK will be set
On Fri, Aug 8, 2014 at 4:54 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Aug 8, 2014 at 10:05 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Aug 7, 2014 at 8:06 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Aug 7, 2014 at 11:46 AM, Bin Cheng bin.ch...@arm.com
On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper drep...@gmail.com wrote:
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse marc.gli...@inria.fr wrote:
__x = result_type(2.0) * __aurng() - 1.0;
You're right, we of course need the negatives as well.
Assuming the 2 coordinates are
On Wed, Aug 13, 2014 at 3:36 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper drep...@gmail.com wrote:
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse marc.gli...@inria.fr wrote:
__x = result_type(2.0) * __aurng() - 1.0;
You're right, we
On Wed, Aug 13, 2014 at 4:40 AM, Jeff Law l...@redhat.com wrote:
On 08/12/14 14:23, Richard Biener wrote:
On August 12, 2014 8:31:16 PM CEST, Jeff Law l...@redhat.com wrote:
On 08/12/14 11:46, Steve Ellcey wrote:
After talking to Jeff Law at the GCC Cauldron I have updated my
switch
On Thu, Aug 7, 2014 at 5:54 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
The case depends on GCC inlining of global function, but the callee won't be
inlined because it's global function and considered over-writable during
On Thu, Aug 7, 2014 at 8:06 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Aug 7, 2014 at 11:46 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As analyzed in PR62032, this patch fixes the latent lto bug by switching
arguments of lto_define_builtins, otherwise vsnprintf-chk.c would
On Fri, Aug 8, 2014 at 4:05 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
On 07/08/14 10:43, Bin Cheng wrote:
Hi,
Case pr61772.c scans specific string in assembly file, and it is run for
many different option combinations. When it's tested against different
lto
option combinations on
On Fri, Aug 8, 2014 at 4:54 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Aug 8, 2014 at 10:05 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Aug 7, 2014 at 8:06 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Aug 7, 2014 at 11:46 AM, Bin Cheng bin.ch...@arm.com
On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
The case depends on GCC inlining of global function, but the callee won't be
inlined because it's global function and considered over-writable during
run-time.
It won't be inlined only if it's tested against -fpic/-fPIC.
Forgot the patch~
On Wed, Aug 6, 2014 at 10:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As quoted from the function
On Fri, Jul 25, 2014 at 8:35 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As quoted from the function difference_cannot_overflow_p,
/* TODO: deeper inspection may be necessary to prove the equality. */
On Mon, Aug 4, 2014 at 2:28 PM, Zhenqiang Chen zhenqiang.c...@arm.com 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)
On Fri, Jul 25, 2014 at 1:27 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:07 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
This is a series of three patches improving induction variable elimination.
Currently GCC only eliminates iv for very specific case when
On Fri, Jul 25, 2014 at 1:35 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Jul 17, 2014 at 11:08 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
As quoted from the function difference_cannot_overflow_p,
/* TODO: deeper inspection may be necessary to prove the equality. */
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
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
Forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
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
Hi, forward to Zdenek for the review.
Thanks,
bin
-- Forwarded message --
From: Bin Cheng bin.ch...@arm.com
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
On Fri, Jul 4, 2014 at 1:17 PM, Bin Cheng bin.ch...@arm.com 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
On Tue, Jul 8, 2014 at 2:50 PM, Jan Hubicka hubi...@ucw.cz 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
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, June 18, 2014 4:31 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in
On Fri, Jul 4, 2014 at 10:44 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent
On Tue, Jul 1, 2014 at 10:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
Sorry for this late reply, I spent some time in understanding the problem.
On Tue, Jun 24, 2014 at 12:36 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Jun 23, 2014 at 11:49 AM, Bin Cheng bin.ch...@arm.com
On Thu, Jul 3, 2014 at 4:15 PM, Richard Earnshaw rearn...@arm.com wrote:
The VFP9 floating-point unit (as occasionally used with ARM9 devices)
has an erratum (760019) whereby it is possible for floating-point
division and square-root instructions to be executed twice. This is not
a problem if
On Wed, Jul 2, 2014 at 7:48 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Mon, May 5, 2014 at 8:21 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Thursday, May 01, 2014 10:03 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Sorry for this late reply, I spent some time in understanding the problem.
On Tue, Jun 24, 2014 at 12:36 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Jun 23, 2014 at 11:49 AM, Bin Cheng bin.ch...@arm.com wrote:
expressions. It's possible to have iv_elimination_compare_lt to do
On Tue, Jul 1, 2014 at 10:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
Sorry for this late reply, I spent some time in understanding the problem.
On Tue, Jun 24, 2014 at 12:36 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Jun 23, 2014 at 11:49 AM, Bin Cheng bin.ch...@arm.com
On Wed, Jun 4, 2014 at 7:18 PM, Charles Baylis
charles.bay...@linaro.org wrote:
On 4 June 2014 10:06, Charles Baylis charles.bay...@linaro.org wrote:
On 4 June 2014 03:11, Bin.Cheng amker.ch...@gmail.com wrote:
Yes, If there is a PR, I can evaluate how this can help and ask
release maintainer
On Tue, Jun 3, 2014 at 10:30 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Tue, 3 Jun 2014, Richard Biener wrote:
On Tue, Jun 3, 2014 at 3:48 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
apparently it is possible to have a PHI in the middle basic block of
value_replacement, so I
...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Wednesday, May 28, 2014 4:53 PM
To: Richard Earnshaw
Cc: gcc-patches List
Subject: RE: [PATCH ARM] Improve ARM memset inlining
Ping^3
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Monday, May 19, 2014 2:40
On Wed, Jun 4, 2014 at 1:50 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 3 Jun 2014, at 18:08, Charles Baylis charles.bay...@linaro.org wrote:
On 3 June 2014 12:08, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 28 May 2014 08:30, Bin.Cheng amker.ch...@gmail.com 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 to be
computed outside of memory reference. The root cause is because aarch64
effectively
Missing patch.
On Wed, May 28, 2014 at 3:02 PM, bin.cheng bin.ch...@arm.com 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,
bin
On Mon, May 12, 2014 at 11:17 AM
On Tue, May 20, 2014 at 1:30 AM, Jeff Law l...@redhat.com wrote:
On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:32 AM, Jeff Law l...@redhat.com wrote:
On 05/16/14 04:07, Bin.Cheng wrote:
But can't you go through movXX to generate either the simple insn on the
ARM
On Tue, May 20, 2014 at 5:02 AM, Mike Stump mikest...@comcast.net wrote:
On May 19, 2014, at 10:30 AM, Jeff Law l...@redhat.com wrote:
Yes, I think it's more than upsizing the mode. There is another
example from one of x86's candidate peephole patch at
On Sat, May 17, 2014 at 12:52 AM, Mike Stump mikest...@comcast.net wrote:
On May 16, 2014, at 3:07 AM, Bin.Cheng amker.ch...@gmail.com wrote:
I don't see how regrename will help resolve [base+offset] false
dependencies. Can you explain? I'd expect effects from
hardreg-copyprop commoning
On Sat, May 17, 2014 at 12:32 AM, Jeff Law l...@redhat.com 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 each other
On Sat, May 17, 2014 at 12:18 AM, Jeff Law l...@redhat.com wrote:
On 05/16/14 04:07, Bin.Cheng wrote:
On Fri, May 16, 2014 at 1:13 AM, Jeff Law l...@redhat.com wrote:
On 05/15/14 10:51, Mike Stump wrote:
On May 15, 2014, at 12:26 AM, bin.cheng bin.ch...@arm.com wrote:
Here comes up
Ping^2
Thanks,
bin
On Mon, May 12, 2014 at 11:17 AM, Bin.Cheng amker.ch...@gmail.com wrote:
Ping.
Thanks,
bin
On Tue, May 6, 2014 at 12:59 PM, bin.cheng bin.ch...@arm.com wrote:
Precisely, I configured gcc with options --with-arch=armv7-a
--with-cpu|--with-tune=cortex-a9.
I read gcc
On Fri, May 16, 2014 at 12:57 AM, Steven Bosscher stevenb@gmail.com 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
load/stores
On Fri, May 16, 2014 at 1:13 AM, Jeff Law l...@redhat.com wrote:
On 05/15/14 10:51, Mike Stump wrote:
On May 15, 2014, at 12:26 AM, bin.cheng bin.ch...@arm.com wrote:
Here comes up with a new GCC pass looking through each basic block
and merging paired load store even they are not adjacent
On Fri, May 16, 2014 at 12:51 AM, Mike Stump mikest...@comcast.net wrote:
On May 15, 2014, at 12:26 AM, bin.cheng bin.ch...@arm.com 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
On Thu, May 15, 2014 at 6:31 PM, Oleg Endo oleg.e...@t-online.de wrote:
Hi,
On 15 May 2014, at 09:26, bin.cheng bin.ch...@arm.com wrote:
Hi,
Targets like ARM and AARCH64 support double-word load store instructions,
and these instructions are generally faster than the corresponding two
load
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
On Tue, May 13, 2014 at 4:59 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Sun, May 11, 2014 at 2:49 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Tue, May 6, 2014 at 6:44 PM, Richard Biener
richard.guent
On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Tue, May 6, 2014 at 6:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
richard.guent
Ping.
Thanks,
bin
On Tue, May 6, 2014 at 12:59 PM, bin.cheng bin.ch...@arm.com 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: Richard Earnshaw
Cc: gcc-patches
On Tue, May 6, 2014 at 6:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
richard.guent...@gmail.com wrote:
Hi,
I split the patch into two and updated the test case
On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Nov 25, 2013 at 7:41 PM, Jeff Law l...@redhat.com wrote:
On 11/25/13 02:22, bin.cheng wrote:
Hi,
I previously committed two patches lowering complex address expression for
IVOPT at http://gcc.gnu.org/ml
-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 wrote:
Hi,
Function output_move_neon now
-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 inlining
Hi Richard, Thanks
701 - 800 of 916 matches
Mail list logo
