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 ex
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.
Have
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
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 = 0x7f
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
>
On 04/24/2015 10:18 AM, Jiong Wang wrote:
2015-04-21 Jiong Wang
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.>
(free_inv_motion_data):
2015-04-28 14:56 GMT+01:00 Matthew Fortune :
>> Hi Matthew,
>>
>> 2015-04-21 15:24 GMT+01:00 Jiong Wang :
>>
>> >
>> > 2015-04-21 Jiong Wang
>> >
>> > gcc/
>> > * loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
>> > (vfp_const_iv): New hash table.
>> > (expensive_addr_check_p): New
> Hi Matthew,
>
> 2015-04-21 15:24 GMT+01:00 Jiong Wang :
>
> >
> > 2015-04-21 Jiong Wang
> >
> > 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
Hi Matthew,
2015-04-21 15:24 GMT+01:00 Jiong Wang :
>
> 2015-04-21 Jiong Wang
>
> 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.>
> (free_i
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 :
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
>>
>> So I think this stage2/3 binary difference is acceptable?
>
>
> No, they should be ident
On 04/21/2015 08:24 AM, Jiong Wang wrote:
Jiong Wang writes:
2015-04-14 18:24 GMT+01:00 Jeff Law :
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, i
Jiong Wang writes:
> 2015-04-14 18:24 GMT+01:00 Jeff Law :
>> 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 alre
2015-02-11 18:18 GMT+00:00 Jiong Wang :
>
> 2015-02-11 Jiong Wang
>
> 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.
> (free_inv_motion_data)
2015-04-14 18:24 GMT+01:00 Jeff Law :
> 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. An
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 i
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 acceptab
2015-02-11 18:18 GMT+00:00 Jiong Wang :
> 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 :
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data
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 :
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.
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
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 wh
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck :
>
> 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 here.
>
> if you reall
On 12/19/2014 06:26 AM, Richard Biener wrote:
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wrote:
2014-12-19 3:51 GMT+00:00 Bin.Cheng :
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
wrote:
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
On 17/12/14 15:54, Richard Biener wr
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 r
> 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 R
On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
wrote:
> 2014-12-19 3:51 GMT+00:00 Bin.Cheng :
>> On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
>> 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
2014-12-19 3:51 GMT+00:00 Bin.Cheng :
> On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
> 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 s
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
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 definition statements f
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 singl
2014-12-18 17:00 GMT+00:00 Jiong Wang :
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 instruc
On 17/12/14 15:54, Richard Biener wrote:
On Mon, Dec 15, 2014 at 4:29 PM, Jiong Wang 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
wrote:
On Thu, Dec 4, 2014 at 12:
On Mon, Dec 15, 2014 at 4:29 PM, Jiong Wang 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
wrote:
>
> On Thu, Dec 4, 2014 at 12:00 PM,
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
wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang wrote:
which means re-associate the constant imm with the virtual frame po
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
wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang wrote:
which means re-associate the constant imm with the virtual frame pointer.
transform
RA <- fixed_
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
wrote:
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang wrote:
which means re-associate the constant imm with the virtual frame pointer.
transform
RA <- fixed_reg + RC
RD <- MEM (RA + const_off
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang 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
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang 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 level loop i
36 matches
Mail list logo
