> On 06/02/14 14:27, Jan Hubicka wrote:
> >>On 06/02/14 12:07, Jan Hubicka wrote:
> >>>
> >>>It is one of reasions why I think it would be cool to do jump threading in
> >>>early opts, too, at least in a lightweidt form.
> >>Conceptually it's pretty easy to do during the into-ssa step. Not
> >>sur
On 06/02/14 14:27, Jan Hubicka wrote:
On 06/02/14 12:07, Jan Hubicka wrote:
It is one of reasions why I think it would be cool to do jump threading in
early opts, too, at least in a lightweidt form.
Conceptually it's pretty easy to do during the into-ssa step. Not
sure it it'd catch the cases
> On 06/02/14 12:07, Jan Hubicka wrote:
> >
> >It is one of reasions why I think it would be cool to do jump threading in
> >early opts, too, at least in a lightweidt form.
> Conceptually it's pretty easy to do during the into-ssa step. Not
> sure it it'd catch the cases you care about though.
Ye
On Mon, Jun 2, 2014 at 11:04 AM, Teresa Johnson wrote:
> On Mon, Jun 2, 2014 at 10:26 AM, Dehao Chen wrote:
>> Just tried with Teresa's patch, the ICE in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 is not resolved.
>
> I will take a look to see why this wasn't fixed by my profile redesi
> We need to rebuild frequency after vrp, otherwise the following code
> in tree-ssa-threadupdate.c will make the frequency larger than
> upper-bound.
>
> /* Excessive jump threading may make frequencies large enough so
> the computation overflows. */
> if (rd->du
On 06/02/14 12:07, Jan Hubicka wrote:
It is one of reasions why I think it would be cool to do jump threading in
early opts, too, at least in a lightweidt form.
Conceptually it's pretty easy to do during the into-ssa step. Not sure
it it'd catch the cases you care about though.
jeff
On Mon, Jun 2, 2014 at 10:26 AM, Dehao Chen wrote:
> Just tried with Teresa's patch, the ICE in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 is not resolved.
I will take a look to see why this wasn't fixed by my profile redesign.
Teresa
>
> Dehao
>
> On Mon, Jun 2, 2014 at 9:45 AM, Jeff
> On 06/02/14 10:17, Dehao Chen wrote:
> >We need to rebuild frequency after vrp, otherwise the following code
> >in tree-ssa-threadupdate.c will make the frequency larger than
> >upper-bound.
> >
> > /* Excessive jump threading may make frequencies large enough so
> > the co
Just tried with Teresa's patch, the ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 is not resolved.
Dehao
On Mon, Jun 2, 2014 at 9:45 AM, Jeff Law wrote:
> On 06/02/14 10:17, Dehao Chen wrote:
>>
>> We need to rebuild frequency after vrp, otherwise the following code
>> in tree-ssa-th
On 06/02/14 10:17, Dehao Chen wrote:
We need to rebuild frequency after vrp, otherwise the following code
in tree-ssa-threadupdate.c will make the frequency larger than
upper-bound.
/* Excessive jump threading may make frequencies large enough so
the computation overflow
We need to rebuild frequency after vrp, otherwise the following code
in tree-ssa-threadupdate.c will make the frequency larger than
upper-bound.
/* Excessive jump threading may make frequencies large enough so
the computation overflows. */
if (rd->dup_blocks[0]->f
> This patch rebuilds frequency after vrp.
Why do you need to rebuild frequency after VRP? I always tought it may be
useful to do VRP as early optimization (modulo to compile time costs),
but I do not think we should unconditionally rebuild frequencies like this...
Honza
>
> Bootstrapped and te
This patch rebuilds frequency after vrp.
Bootstrapped and testing on-going. OK for trunk if test pass?
Thanks,
Dehao
gcc/ChangeLog:
2014-06-02 Dehao Chen
PR tree-optimization/61384
* tree-vrp.c (execute_vrp): rebuild frequency after vrp.
gcc/testsuite/ChangeLog:
2014-06-02
13 matches
Mail list logo
