-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
On 04/17/14 04:07, Bin.Cheng wrote
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
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/memcpy
On Tue, Apr 22, 2014 at 2:59 AM, Xinliang David Li davi...@google.com 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
On Thu, Apr 17, 2014 at 1:30 PM, Jeff Law l...@redhat.com 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 logical_op_short_circuit
targets
On Thu, Apr 10, 2014 at 8:18 AM, Wei Mi w...@google.com wrote:
Hi,
For the testcase 1.c
#include emmintrin.h
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
, bin.cheng bin.ch...@arm.com 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_circuit targets. Is it ok?
Ok if you verified that this syntax
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
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
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
:
On Fri, Feb 28, 2014 at 1:52 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Feb 24, 2014 at 9:12 PM, bin.cheng bin.ch...@arm.com 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
Thanks for reporting this, I will look into it.
Thanks,
bin
On Fri, Feb 28, 2014 at 8:52 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Feb 24, 2014 at 9:12 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
This patch is to fix regression reported in PR60280 by removing forward loop
headers/latches
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 h...@bitrange.com wrote:
On Tue, 25 Feb 2014, bin.cheng wrote:
Hi,
This patch is to fix regression reported in PR60280 by removing
, Feb 25, 2014 at 6:12 AM, bin.cheng bin.ch...@arm.com 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 cleanup is shared by all
optimizers. Some tests has
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
On Thu, Feb 20, 2014 at 10:51 PM, Richard Biener rguent...@suse.de 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
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 bin.ch...@arm.com
* 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 test case
Hi,
The case
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 rguent...@suse.de wrote:
This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes
On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener rguent...@suse.de 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 a bugzilla about
On Mon, Jan 13, 2014 at 2:29 PM, Jeff Law l...@redhat.com wrote:
On 01/11/14 02:21, Bin.Cheng wrote:
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
I reduced the case and attached ivopt dumps with/without
On Sat, Jan 11, 2014 at 2:42 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Dec 11, 2013 at 4:18 AM, Jeff Law l...@redhat.com wrote:
On 12/10/13 00:01, bin.cheng wrote:
Emm, some kind of. See the cost of iv candidate set consists of several
parts, the representation cost in cost pair
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
I reduced the case and attached ivopt dumps with/without the patch.
It seems the patch is doing right thing and choosing better
candidates, most likely
On Wed, Dec 11, 2013 at 4:17 PM, Jakub Jelinek ja...@redhat.com 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 free_affine_expand_cache
-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
simplifying PEELED chrec
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek ja...@redhat.com 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. I
On Wed, Dec 11, 2013 at 4:31 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Dec 9, 2013 at 6:46 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
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 6:50 AM, Jakub Jelinek ja...@redhat.com 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. I
-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 evolution
On Mon, Dec 9
-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 pending IVOPT patches
On 11/26
On Mon, Dec 9, 2013 at 12:00 PM, Jeff Law l...@redhat.com 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
talk of throttling PRE to leave things
On Fri, Dec 6, 2013 at 2:10 PM, Jeff Law l...@redhat.com wrote:
On 11/26/13 03:52, Bin.Cheng wrote:
On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law l...@redhat.com wrote:
On 11/25/13 02:11, Bin.Cheng wrote:
Slightly tune to make iv cand choosing algorithm more accurate:
http://gcc.gnu.org/ml
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 i_13(5),
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:
Unless there's a PR for this problem, I think this needs to wait.
I agree. Btw, please split the patch.
Yes
On Fri, Dec 6, 2013 at 7:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Dec 6, 2013 at 11:40 AM, Bin.Cheng amker.ch...@gmail.com wrote:
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
On Sat, Dec 7, 2013 at 3:20 AM, Jeff Law l...@redhat.com 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
not to do some specific transformation
On Thu, Dec 5, 2013 at 6:57 AM, Joseph S. Myers jos...@codesourcery.com 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 @@
On Sat, Nov 30, 2013 at 12:34 AM, Richard Earnshaw rearn...@arm.com 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 context information
On Fri, Nov 29, 2013 at 6:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 29, 2013 at 8:52 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Nov 28, 2013 at 8:06 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw rearn...@arm.com
On Sat, Nov 30, 2013 at 12:34 AM, Richard Earnshaw rearn...@arm.com 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 context information
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw rearn...@arm.com 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
Sent: Monday, September 02, 2013 3:09 PM
To: Richard
On Thu, Nov 28, 2013 at 8:06 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw rearn...@arm.com 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
Ping^2
Thanks,
bin
On Fri, Nov 22, 2013 at 3:32 PM, bin.cheng bin.ch...@arm.com 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)
+++
Hi all,
There are still two patches on IVOPT pending for review now. Since
others have already approved and applied, I am wondering whether these
two can be reviewed and get in if ok.
Improve IVOPT to handle outside and inside loop iv uses differently in GCC:
Hi,
I previously committed two patches lowering complex address expression for
IVOPT at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html and
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01103.html
When I bootstrapping GCC I found there were some peculiar cases like
MEM[ptr+CST] + ,
On Sat, Nov 23, 2013 at 4:05 PM, Wei Mi w...@google.com wrote:
On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
rakd...@iuuk.mff.cuni.cz wrote:
Hi,
This patch works on the intrinsic calls handling issue in IVOPT mentioned
here:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
In
On Fri, Nov 22, 2013 at 10:11 PM, Zdenek Dvorak
rakd...@iuuk.mff.cuni.cz wrote:
Hi,
If a pointer typed use is plainly value passed to a func call, it is
not an address use, right? But as you said, x86 lea may help here.
But that's what you are matching ... (well, for builtins you know
On Sat, Nov 23, 2013 at 1:57 AM, Wei Mi w...@google.com wrote:
On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi w...@google.com wrote:
I think the problem can be showed by below example:
struct tag
{
int a[10];
int b;
};
struct tag s;
int foo(int len)
{
int i = 0;
int sum = 0;
for (i
I don't know very much about the problem but willing to study since I
am looking into IVO recently :)
--- tree-ssa-loop-ivopts.c (revision 204792)
+++ tree-ssa-loop-ivopts.c (working copy)
@@ -135,6 +135,8 @@ struct iv
tree ssa_name; /* The ssa name with the value. */
Ping and CC Zdenek with the right email.
Thanks,
bin
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Wednesday, November 06, 2013 5:51 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Biener; o...@ucw.cz
Subject
PING.
Hi, there is a patch at
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01353.html which slipped away.
Thanks,
bin
On Tue, Nov 19, 2013 at 10:09 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Bernd Schmidt [mailto:ber...@codesourcery.com]
Sent: Monday, November 18, 2013 8:05 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH GCC]Compute, cache and use cost of auto
Ping^2
Thanks,
bin
On Tue, Nov 12, 2013 at 3:08 PM, bin.cheng bin.ch...@arm.com wrote:
Ping in this one.
Hi Bernd, could you please help us on this one?
Sorry for the inconvenience.
Thanks,
bin
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Monday
, bin.cheng wrote:
2013-11-01 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-ivopts.c (enum ainc_type): New.
(address_cost_data): New field.
(get_address_cost): Compute auto-increment rtx cost in ainc_costs.
Use ainc_costs for auto-increment rtx patterns.
Cleanup TWS.
I
Hi,
The algorithm choosing candidates in IVOPT has some defects that optimal iv
set can't be found in some cases. This patch slightly tunes the algorithm
to make it more accurate. The reasons are:
1) Changes in iv_ca_extend. Dependences could be changed in the loop,
causing check condition
On Thu, Nov 7, 2013 at 6:47 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Nov 6, 2013 at 6:06 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi,
bin.cheng bin.ch...@arm.com writes:
Index: gcc/tree-ssa-loop-ivopts.c
On Wed, Nov 13, 2013 at 7:26 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Nov 13, 2013 at 12:18 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Thu, Nov 7, 2013 at 6:47 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Nov 6, 2013 at 6:06 PM, Richard Sandiford
Ping in this one.
Hi Bernd, could you please help us on this one?
Please ignore the previous ping message because I used the wrong email
account.
Sorry for the inconvenience.
Thanks,
bin
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Monday, November 04, 2013
On Fri, Nov 8, 2013 at 10:06 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Nov 8, 2013 at 2:41 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
This patch refactors force_expr_to_var_cost and handles type conversion
along with other tree nodes. It is split from the patch posted
On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump mikest...@comcast.net wrote:
On Nov 7, 2013, at 5:13 PM, Mingjie Xing mingjie.x...@gmail.com wrote:
Well, it is my understanding that the warning should be emitted for a
volatile variable only if it is not accessed. Initialization means
accessing,
On Fri, Nov 8, 2013 at 5:39 PM, Mike Stump mikest...@comcast.net wrote:
On Nov 8, 2013, at 1:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump mikest...@comcast.net wrote:
On Nov 7, 2013, at 5:13 PM, Mingjie Xing mingjie.x...@gmail.com wrote:
Well
Hi,
This patch refactors force_expr_to_var_cost and handles type conversion
along with other tree nodes. It is split from the patch posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html
Bootstrap and test with the patch lowering address expressions on
x86/x86_64/arm. Is it OK?
Hi,
GCC IVOPT has a problem that it doesn't differentiate between iv uses
outside of loop from inside ones. It computes cost for outside iv use just
like inside ones, which is wrong because outside iv use should be computed
along loop exit edge and the cost should be amortized against loop
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Tuesday, November 05, 2013 8:18 PM
To: Bin Cheng
Cc: GCC Patches
Subject: Re: [PATCH GCC]Simplify address expression in IVOPT
On Tue, Nov 5, 2013 at 11:13 AM, bin.cheng bin.ch...@arm.com wrote
On Thu, Nov 7, 2013 at 1:06 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi,
bin.cheng bin.ch...@arm.com writes:
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c(revision 203267)
+++ gcc
On Thu, Nov 7, 2013 at 11:53 AM, Mingjie Xing mingjie.x...@gmail.com wrote:
2013/11/6 Richard Biener richard.guent...@gmail.com:
You miss a testcase.
Also why should the warning be omitted for unused automatic
volatile variables? They cannot be used in any way.
Richard.
Thanks. I've
-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]Simplify address expression in IVOPT
-Original
On Tue, Nov 5, 2013 at 7:19 PM, Yufeng Zhang yufeng.zh...@arm.com wrote:
On 11/05/13 10:13, bin.cheng wrote:
Index: gcc/tree-affine.c
===
--- gcc/tree-affine.c (revision 204117)
+++ gcc/tree-affine.c (working copy
On Tue, Nov 5, 2013 at 8:29 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Nov 5, 2013 at 1:18 PM, Yufeng Zhang yufeng.zh...@arm.com wrote:
On 11/05/13 11:45, Bin.Cheng wrote:
On Tue, Nov 5, 2013 at 7:19 PM, Yufeng Zhangyufeng.zh...@arm.com wrote:
On 11/05/13 10:13
-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, bin.cheng bin.ch...@arm.com wrote
On Mon, Nov 4, 2013 at 7:38 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng bin.ch...@arm.com 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
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
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:
On Mon, Oct 21, 2013 at 8:21 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Oct 18, 2013 at 5:48 PM, Bin.Cheng amker.ch...@gmail.com 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
On Fri, Oct 18, 2013 at 7:18 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Oct 17, 2013 at 7:52 AM, bin.cheng bin.ch...@arm.com 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
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
richard.guent...@gmail.com wrote:
On Thu, Oct 17, 2013 at 7:52 AM, bin.cheng bin.ch...@arm.com wrote
of TREE_INT_CST_LOW.
gcc/testsuite/ChangeLog
2013-10-17 Bin Cheng bin.ch...@arm.com
* 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
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng bin.ch...@arm.com wrote:
I don't think you need
+ /* Sign extend off if expr is in type which has lower precision
+ than HOST_WIDE_INT
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
richard.guent...@gmail.com wrote:
On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng bin.ch...@arm.com wrote
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng bin.ch...@arm.com wrote:
I don't think you need
+ /* Sign extend off if expr is in type which has lower precision
+ than HOST_WIDE_INT
-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
After
-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 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: Friday, September 27, 2013 1:07 PM
To: 'Richard Biener'
Cc: GCC Patches
Subject: RE: [PATCH]Fix computation of offset in ivopt
-Original Message
-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
On Tue, Sep 24, 2013 at 1
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: GCC Patches; Richard Earnshaw
Subject: RE
-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:13 AM, bin.cheng bin.ch...@arm.com wrote
-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, 2013 at 12:00 PM, bin.cheng bin.ch
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
On Tue, Sep 24, 2013 at 6:12 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Sep 24, 2013 at 8:20 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
Or even [reg*scale] (not sure about that). But yes, at least reg*scale +
offset
and reg*scale + reg
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
-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 address expression on ARM
-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
-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, I've been
-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
Subject: RE: [PATCH GCC]Catch more
On Tue, Sep 10, 2013 at 9:30 PM, Bill Schmidt wschm...@linux.vnet.ibm.com
wrote:
On Tue, 2013-09-10 at 15:41 +0800, bin.cheng wrote:
On Mon, Sep 9, 2013 at 11:35 PM, Bill Schmidt wschm...@linux.vnet.ibm.com
wrote:
I rely on size_binop to convert T2 into sizetype, because T2' may
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
On Tue, Sep 10, 2013 at 3:30 AM, Steven Bosscher stevenb@gmail.com 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
On Mon, Sep 9, 2013 at 11:35 PM, Bill Schmidt wschm...@linux.vnet.ibm.com
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
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 wschm...@linux.vnet.ibm.com
wrote:
+ int (i * S).
+ Otherwise, just return double int zero. */
This is sufficient, since you are properly checking
801 - 900 of 916 matches
Mail list logo
