> On Oct 17, 2016, at 12:26 PM, Bin.Cheng wrote:
>
> On Sat, Oct 15, 2016 at 3:07 AM, kugan
> wrote:
>> Hi Bin,
>>
>> On 15/10/16 00:15, Bin Cheng wrote:
>>>
>>> +/* Test for likely overcommitment of vector hardware resources. If a
On Sat, Oct 15, 2016 at 3:07 AM, kugan
wrote:
> Hi Bin,
>
> On 15/10/16 00:15, Bin Cheng wrote:
>>
>> +/* Test for likely overcommitment of vector hardware resources. If a
>> + loop iteration is relatively large, and too large a percentage of
>> +
On Sat, Oct 15, 2016 at 01:07:12PM +1100, kugan wrote:
> Hi Bin,
>
> On 15/10/16 00:15, Bin Cheng wrote:
> >+/* Test for likely overcommitment of vector hardware resources. If a
> >+ loop iteration is relatively large, and too large a percentage of
> >+ instructions in the loop are
Hi Bin,
On 15/10/16 00:15, Bin Cheng wrote:
+/* Test for likely overcommitment of vector hardware resources. If a
+ loop iteration is relatively large, and too large a percentage of
+ instructions in the loop are vectorized, the cost model may not
+ adequately reflect delays from
Hi,
It is suspected that for some large loops with too many vect_insns after
vectorization, the performance will be regressed because of various reasons.
Two possible reasons are:
1) Suggested by powerpc backend, large loops with too many vect_insns may jam
vector unit's pipeline.
2)