> Thanks, Honza,
>
> Then shall I check in the following patch to trunk (after testing)?
Yes, this is OK (with a changelog).
Thanks!
Honza
Thanks, Honza,
Then shall I check in the following patch to trunk (after testing)?
Dehao
Index: gcc/testsuite/gcc.dg/predict-7.c
===
--- gcc/testsuite/gcc.dg/predict-7.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-7.c(revis
> On Tue, Jul 31, 2012 at 6:56 PM, Jan Hubicka wrote:
> >> >
> >> > Yeah, this may also work. The reason it is not done is that
> >> > 1) it seemed expensive to force CFG changes just to compute profile
> >> > decade ago
> >> > 2) cfgcleanup afterwards will anyway remove the headers again.
> >
On Tue, Jul 31, 2012 at 6:56 PM, Jan Hubicka wrote:
>> >
>> > Yeah, this may also work. The reason it is not done is that
>> > 1) it seemed expensive to force CFG changes just to compute profile
>> > decade ago
>> > 2) cfgcleanup afterwards will anyway remove the headers again.
>> > So I o
> >
> > Yeah, this may also work. The reason it is not done is that
> > 1) it seemed expensive to force CFG changes just to compute profile decade
> > ago
> > 2) cfgcleanup afterwards will anyway remove the headers again.
> > So I originally hoped to do the right thing without normalization
On Tue, Jul 31, 2012 at 12:43 PM, Richard Guenther
wrote:
> On Tue, Jul 31, 2012 at 12:38 PM, Jan Hubicka wrote:
>>> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote:
>>> > Are you suggesting a patch like this:
>>> >
>>> > Index: gcc/predict.c
>>> >
On Tue, Jul 31, 2012 at 12:38 PM, Jan Hubicka wrote:
>> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote:
>> > Are you suggesting a patch like this:
>> >
>> > Index: gcc/predict.c
>> > ===
>> > --- gcc/predict.c (revision 189
> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote:
> > Are you suggesting a patch like this:
> >
> > Index: gcc/predict.c
> > ===
> > --- gcc/predict.c (revision 189835)
> > +++ gcc/predict.c (working copy)
> > @@ -1319
On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote:
> Are you suggesting a patch like this:
>
> Index: gcc/predict.c
> ===
> --- gcc/predict.c (revision 189835)
> +++ gcc/predict.c (working copy)
> @@ -1319,6 +1319,7 @@
>
> Are you suggesting a patch like this:
>
> Index: gcc/predict.c
> ===
> --- gcc/predict.c (revision 189835)
> +++ gcc/predict.c (working copy)
> @@ -1319,6 +1319,7 @@
>tree loop_bound_var = NULL;
>tree loop_iv
Are you suggesting a patch like this:
Index: gcc/predict.c
===
--- gcc/predict.c (revision 189835)
+++ gcc/predict.c (working copy)
@@ -1319,6 +1319,7 @@
tree loop_bound_var = NULL;
tree loop_iv_base = NULL;
On Tue, Jul 31, 2012 at 5:17 AM, Dehao Chen wrote:
> Hi,
>
> This patch fixed the problem when a LOOP_EXIT edge for the inner loop
> happened to target at the LOOP_LATCH of the outer loop. As the outer
> loop is processed first, the LOOP_BRANCH heuristic is honored
> (first_match), thus the inner
Hi,
This patch fixed the problem when a LOOP_EXIT edge for the inner loop
happened to target at the LOOP_LATCH of the outer loop. As the outer
loop is processed first, the LOOP_BRANCH heuristic is honored
(first_match), thus the inner loop's trip count is 0. (The attached
unittest demonstrates thi
13 matches
Mail list logo
