> 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
12 matches
Mail list logo
