[AArch64] Penalize vector cost for large loops with too many vect insns.

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) Vectorizer may generate bad code, especially if the loop has many different memory accesses.  These memory accesses could refer to different memory objects, or the same object but with different constant offset.  This may result in more base register living from loop preheader, as well as high register pressure.
This patch penalize vector cost for such loops in order to skip vectorizing.  The idea is totally borrowed from powerpc backend.  I adjusted the parameter a bit to get better performance on AArch64.  It improves several cases in spec, especially 459.GemsFDTD by ~15%.

Bootstrap and test on AArch64. Is it OK?

2016-10-13  Bin Cheng  <bin.cheng@arm.com>

	* config/aarch64/aarch64.c (struct aarch64_vect_loop_cost_data): New.
	(aarch64_add_stmt_cost): Use struct aarch64_vect_loop_cost_data.
	(aarch64_init_cost, aarch64_density_test): New funcs.
	(aarch64_finish_cost, aarch64_destroy_cost_data): New funcs.
	(TARGET_VECTORIZE_INIT_COST): New macro.
	(TARGET_VECTORIZE_FINISH_COST): New macro.
	(TARGET_VECTORIZE_DESTROY_COST_DATA): New macro.

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 unavailable vector resources.
> +   Penalize the loop body cost for this case.  */
> +
> +static void
> +aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
> +{
> +  const int DENSITY_PCT_THRESHOLD = 85;
> +  const int DENSITY_SIZE_THRESHOLD = 128;
> +  const int DENSITY_PENALTY = 10;
> +  struct loop *loop = data->loop_info;
> +  basic_block *bbs = get_loop_body (loop);

Is this worth being part of the cost model such that it can have 
different defaults for different micro-architecture?


Thanks,
Kugan

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 vectorized, the cost model may not
> >+   adequately reflect delays from unavailable vector resources.
> >+   Penalize the loop body cost for this case.  */
> >+
> >+static void
> >+aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
> >+{
> >+  const int DENSITY_PCT_THRESHOLD = 85;
> >+  const int DENSITY_SIZE_THRESHOLD = 128;
> >+  const int DENSITY_PENALTY = 10;
> >+  struct loop *loop = data->loop_info;
> >+  basic_block *bbs = get_loop_body (loop);
> 
> Is this worth being part of the cost model such that it can have
> different defaults for different micro-architecture?

I think this is a relevant point, even if we do choose these values for
the generic compilation model, we may want to tune this on a per-core basis.

So, pulling these magic numbers out in to a new field in the CPU tuning
structures (tune_params) is probably the right approach.

Thanks,
James

On Sat, Oct 15, 2016 at 3:07 AM, kugan
<kugan.vivekanandarajah@linaro.org> 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 vectorized, the cost model may not
>> +   adequately reflect delays from unavailable vector resources.
>> +   Penalize the loop body cost for this case.  */
>> +
>> +static void
>> +aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
>> +{
>> +  const int DENSITY_PCT_THRESHOLD = 85;
>> +  const int DENSITY_SIZE_THRESHOLD = 128;
>> +  const int DENSITY_PENALTY = 10;
>> +  struct loop *loop = data->loop_info;
>> +  basic_block *bbs = get_loop_body (loop);
>
>
> Is this worth being part of the cost model such that it can have different
> defaults for different micro-architecture?
Hi,
I don't know.  From my running, this penalizing function looks like a
quite benchmark specific tuning.  If that's the case, tuning for
different micro architecture may not give meaningful different
results, at the cost of three parameters.
Hi Bill,  I guess you are the original author?  Do you recall any
motivation of this code or have some comments?  Thanks very much.
Meanwhile, I can do some experiments on different AArch64 processors.

Thanks,
bin

> On Oct 17, 2016, at 12:26 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> 
> On Sat, Oct 15, 2016 at 3:07 AM, kugan
> <kugan.vivekanandarajah@linaro.org> 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 vectorized, the cost model may not
>>> +   adequately reflect delays from unavailable vector resources.
>>> +   Penalize the loop body cost for this case.  */
>>> +
>>> +static void
>>> +aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
>>> +{
>>> +  const int DENSITY_PCT_THRESHOLD = 85;
>>> +  const int DENSITY_SIZE_THRESHOLD = 128;
>>> +  const int DENSITY_PENALTY = 10;
>>> +  struct loop *loop = data->loop_info;
>>> +  basic_block *bbs = get_loop_body (loop);
>> 
>> 
>> Is this worth being part of the cost model such that it can have different
>> defaults for different micro-architecture?
> Hi,
> I don't know.  From my running, this penalizing function looks like a
> quite benchmark specific tuning.  If that's the case, tuning for
> different micro architecture may not give meaningful different
> results, at the cost of three parameters.
> Hi Bill,  I guess you are the original author?  Do you recall any
> motivation of this code or have some comments?  Thanks very much.
> Meanwhile, I can do some experiments on different AArch64 processors.

Hi Bin,

Yes, this is specific tuning due to problems observed on a
POWER model.  I don't necessarily recommend this approach for
other architectures without appropriate experimental verification
and tuning.

Bill

> 
> Thanks,
> bin
>