> Hi Honza,
OK,
thanks!
Honz
> There is the 3rd version patch fixing mentioned issues. Is it OK?
>
> Thanks,
> bin
> diff --git a/gcc/testsuite/gcc.dg/vect/pr79347.c
> b/gcc/testsuite/gcc.dg/vect/pr79347.c
> index 586c638..6825420 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr79347.c
> +++ b/gcc/
On Tue, Feb 21, 2017 at 3:49 PM, Jan Hubicka wrote:
>> 2017-02-21 Bin Cheng
>>
>> PR tree-optimization/77536
>> * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
>> (tree_transform_and_unroll_loop): Use above function to compute the
>> estimated niter of unrolled loop and use it
> 2017-02-21 Bin Cheng
>
> PR tree-optimization/77536
> * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
> (tree_transform_and_unroll_loop): Use above function to compute the
> estimated niter of unrolled loop and use it when scaling profile.
> * tree-ssa-loop-manip.h niter_for_
On Mon, Feb 20, 2017 at 4:05 PM, Jan Hubicka wrote:
>> BTW, if we use gcov_type in calculation from
>> expected_loop_iterations_unbounded,
>> how should we adjust the number for calling scale_loop_frequencies
>> which has int type? In extreme case, gcov_type could be out of int's
>> range, we ha
On Mon, Feb 20, 2017 at 4:05 PM, Jan Hubicka wrote:
>> BTW, if we use gcov_type in calculation from
>> expected_loop_iterations_unbounded,
>> how should we adjust the number for calling scale_loop_frequencies
>> which has int type? In extreme case, gcov_type could be out of int's
>> range, we ha
> BTW, if we use gcov_type in calculation from
> expected_loop_iterations_unbounded,
> how should we adjust the number for calling scale_loop_frequencies
> which has int type? In extreme case, gcov_type could be out of int's
> range, we have to cap the value anyway. But yes, 1 in
> expect_lo
On Mon, Feb 20, 2017 at 3:17 PM, Jan Hubicka wrote:
>> > + /* Without profile feedback, loops for which we do not know a better
>> > estimate
>> > + are assumed to roll 10 times. When we unroll such loop, it appears
>> > to
>> > + roll too little, and it may even seem to be cold. To a
> > + /* Without profile feedback, loops for which we do not know a better
> > estimate
> > + are assumed to roll 10 times. When we unroll such loop, it appears to
> > + roll too little, and it may even seem to be cold. To avoid this, we
> > + ensure that the created loop appears to
On Mon, Feb 20, 2017 at 2:02 PM, Jan Hubicka wrote:
>> > 2017-02-16 Bin Cheng
>> >
>> > PR tree-optimization/77536
>> > * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
>> > (tree_transform_and_unroll_loop): Use above function to compute the
>> >
> > 2017-02-16 Bin Cheng
> >
> > PR tree-optimization/77536
> > * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
> > (tree_transform_and_unroll_loop): Use above function to compute the
> > estimated niter of unrolled loop.
> > * tree-ssa-lo
On Thu, Feb 16, 2017 at 6:48 PM, Bin Cheng wrote:
> Hi,
> After fixing PR79347, the main problem with vectorizer is we scale down
> profiling counters
> for vect_loop by VF, regardless of context CFG's profiling information. This
> is wrong and
> sometimes makes vect_loop not hot code, which ma
On 02/16/2017 11:48 AM, Bin Cheng wrote:
> BTW, it may also help PR78116? Hi Pat, could you please help verify this?
> Thanks!
The first testcase in pr78116 no longer contains loads from spill in the
loop even before your patch. When built with your patch, there are four
additional register cop
Hi,
After fixing PR79347, the main problem with vectorizer is we scale down
profiling counters
for vect_loop by VF, regardless of context CFG's profiling information. This
is wrong and
sometimes makes vect_loop not hot code, which may confuses following
optimizers. This
patch generates well-fo
13 matches
Mail list logo
