On 09/02/2015 07:36 AM, Jiong Wang wrote:
For the record, after Bin's recent tree-ssa-ivopt improvement originated
from PR62173, this patch is not benefitial anymore.
It happens sometimes.
I have stopped working on this patch. Thanks for those time spent on
reviewing and discussing on this.
Jeff Law writes:
> On 05/21/2015 02:46 PM, Jiong Wang wrote:
>>
>> Thanks for these thoughts.
>>
>> I tried but still can't prove this transformation will not introduce
>> extra pointer overflow even given it's reassociation with vfp, although
>> my first impression is it do will not introduce
On 05/21/2015 02:46 PM, Jiong Wang wrote:
Thanks for these thoughts.
I tried but still can't prove this transformation will not introduce
extra pointer overflow even given it's reassociation with vfp, although
my first impression is it do will not introduce extra risk in real
application.
Jeff Law writes:
On 05/14/2015 03:13 PM, Jiong Wang wrote:
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
On 04/24/2015 10:18 AM, Jiong Wang wrote:
2015-04-21 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
(init_inv_motion_data): Initialize new variables.
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
0x7fff + -4 = 0x7ffb
0x7ffb + 3 = 0x7ffe
If
On 05/14/2015 03:13 PM, Jiong Wang wrote:
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
0x7fff + -4 =
Hi Matthew,
2015-04-21 15:24 GMT+01:00 Jiong Wang jiong.w...@arm.com:
2015-04-21 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
2015-04-28 14:56 GMT+01:00 Matthew Fortune matthew.fort...@imgtec.com:
Hi Matthew,
2015-04-21 15:24 GMT+01:00 Jiong Wang jiong.w...@arm.com:
2015-04-21 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
Hi Matthew,
2015-04-21 15:24 GMT+01:00 Jiong Wang jiong.w...@arm.com:
2015-04-21 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
(init_inv_motion_data):
Jeff Law writes:
On 04/21/2015 08:24 AM, Jiong Wang wrote:
Jiong Wang writes:
2015-04-14 18:24 GMT+01:00 Jeff Law l...@redhat.com:
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a
On 04/21/2015 08:24 AM, Jiong Wang wrote:
Jiong Wang writes:
2015-04-14 18:24 GMT+01:00 Jeff Law l...@redhat.com:
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's
Jiong Wang writes:
2015-04-14 18:24 GMT+01:00 Jeff Law l...@redhat.com:
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's a
bug - which, it seems, you've already
2015-02-11 18:18 GMT+00:00 Jiong Wang jiong.w...@arm.com:
2015-02-11 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
(init_inv_motion_data): Initialize new
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's a
bug - which, it seems, you've already found, too.
RIght. And so the natural question is how to fix.
At first glance
On Tue, Apr 14, 2015 at 5:06 PM, Jiong Wang wrote:
but, after some investigation I found gcc actually generate difference
code when debug info enabled because
DEBUG_INSN will affect data flow analysis.
It should not, so that's a bug.
So I think this stage2/3 binary difference is acceptable?
2015-02-11 18:18 GMT+00:00 Jiong Wang jiong.w...@arm.com:
On 11/02/15 14:21, Kenneth Zadeck wrote:
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN
2015-04-14 18:24 GMT+01:00 Jeff Law l...@redhat.com:
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's a
bug - which, it seems, you've already found, too.
RIght. And
On 11/02/15 14:21, Kenneth Zadeck wrote:
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of the defs that reach it. I believe that
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data structure that
connects each use with all of the defs that reach it. I believe that this
is the opposite of what you want
2014-12-19 3:51 GMT+00:00 Bin.Cheng amker.ch...@gmail.com:
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On 17/12/14 15:54, Richard Biener wrote:
ick. I realize we don't have SSA form on RTL
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wong.kwongyuan.to...@gmail.com wrote:
2014-12-19 3:51 GMT+00:00 Bin.Cheng amker.ch...@gmail.com:
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On
still can anyone confirm that it is safe to re-use REG_DEAD info there
without calling df_note_add_problem and df_analysis first? or I am
using those info passed down from the previous pass which calculated
these info and maybe broken?
It is generally _not_ safe to consume REG_UNUSED and
On Fri, Dec 19, 2014 at 11:51:06AM +0800, Bin.Cheng wrote:
yes, we want to restrict the transformation on single-use pseudo only,
and it's better the transformation could re-use existed info and helper
function to avoid increase compile time. but I haven't found anything I
can reuse at the
On 12/19/2014 06:26 AM, Richard Biener wrote:
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wong.kwongyuan.to...@gmail.com wrote:
2014-12-19 3:51 GMT+00:00 Bin.Cheng amker.ch...@gmail.com:
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Thu, Dec 18,
On 17/12/14 15:54, Richard Biener wrote:
On Mon, Dec 15, 2014 at 4:29 PM, Jiong Wang jiong.w...@arm.com wrote:
On 15/12/14 15:28, Jiong Wang wrote:
On 04/12/14 19:32, Jiong Wang wrote:
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
2014-12-18 17:00 GMT+00:00 Jiong Wang jiong.w...@arm.com:
ok for trunk?
gcc/
PR62173
loop-invariant.c.c (expensive_addr): New hash_table.
(need_expensive_addr_check_p): New bool.
(find_exits): Rename to find_exists_and_reshuffle.
Support re-shuffle instructions for
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On 17/12/14 15:54, Richard Biener wrote:
ick. I realize we don't have SSA form on RTL but doesn't DF provide
at least some help in looking up definition statements for pseudos?
In fact we want to restrict the transform to single-use
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On 17/12/14 15:54, Richard Biener wrote:
ick. I realize we don't have SSA form on RTL but doesn't DF provide
at least some help in looking up
On Mon, Dec 15, 2014 at 4:29 PM, Jiong Wang jiong.w...@arm.com wrote:
On 15/12/14 15:28, Jiong Wang wrote:
On 04/12/14 19:32, Jiong Wang wrote:
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 4, 2014
On 04/12/14 19:32, Jiong Wang wrote:
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang jiong.w...@arm.com wrote:
which means re-associate the constant imm with the virtual
On 15/12/14 15:28, Jiong Wang wrote:
On 04/12/14 19:32, Jiong Wang wrote:
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang jiong.w...@arm.com wrote:
which means
For PR62173, the ideal solution is to resolve the problem on tree level ivopt
pass.
While, apart from the tree level issue, PR 62173 also exposed another two RTL
level issues.
one of them is looks like we could improve RTL level loop invariant hoisting by
re-shuffle insns.
for Seb's testcase
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang jiong.w...@arm.com wrote:
For PR62173, the ideal solution is to resolve the problem on tree level
ivopt pass.
While, apart from the tree level issue, PR 62173 also exposed another two
RTL level issues.
one of them is looks like we could improve RTL
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang jiong.w...@arm.com wrote:
For PR62173, the ideal solution is to resolve the problem on tree level
ivopt pass.
While, apart from the tree level issue, PR 62173 also
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang jiong.w...@arm.com wrote:
which means re-associate the constant imm with the virtual frame pointer.
transform
RA -
37 matches
Mail list logo
