Hi all,

The hook TARGET_ESTIMATED_POLY_VALUE allows a target to give an estimate for a poly_int run-time value.
It is used exclusively in tuning decisions, things like estimated loop iterations, probabilities etc.
It is not relied on for correctness.

If we know the SVE width implemented in hardware we can make more more
informed decisions in the implementation of TARGET_ESTIMATED_POLY_VALUE,
even when compiling for VLA vectorisation.

This patch adds an sve_width field to our tuning structs and sets it for
the current CPU tunings.

A new value is introduced to the aarch64_sve_vector_bits_enum enum that indicates
that SVE is not available: SVE_NOT_IMPLEMENTED. I set it to the same value as SVE_SCALABLE
so that parts of the aarch64 backend that follow the pattern:
if (vector_width == SVE_SCALABLE)
   do_vla_friendly_action ()
else
   assume_specific_width_for_correctness ()

continue to work without change, but the CPU tuning structs can use a more
appropriate moniker for indicating the absence of SVE.

This sets sve_width to SVE_NOT_IMPLEMENTED for all cores.
I aim to add an -moverride switch in the next patch that allows a power user to experiment
with different values of it for investigations.

Bootstrapped and tested on aarch64-none-linux-gnu.

Thanks,
Kyrill

2018-12-07  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * config/aarch64/aarch64-opts.h (aarch64_sve_vector_bits_enum):
     Add SVE_NOT_IMPLEMENTED value.
     * config/aarch64/aarch64-protos.h (struct tune_params): Add sve_width
     field.
     * config/aarch64/aarch64.c (generic_tunings,cortexa35_tunings,
     cortexa53_tunings, cortexa57_tunings, cortexa72_tunings,
     cortexa73_tunings, exynosm1_tunings, thunderx_tunings,
     thunderx_tunings, tsv110_tunings, xgene1_tunings, qdf24xx_tunings,
     saphira_tunings, thunderx2t99_tunings, emag_tunings):
     Specify sve_width.
     (aarch64_estimated_poly_value): Define.
     (TARGET_ESTIMATED_POLY_VALUE): Define.