Re: [PATCH, ARM, ping] Use a MULTILIB_REQUIRED approach for aprofile multilib

[Thomas Preudhomme <thomas.preudhomme@foss.arm.com>]

Ping?

Best regards,

Thomas

On 10/08/16 14:51, Thomas Preudhomme wrote:
> Hi,
>
> Currently, the Makefile fragment for ARM aprofile multilib is using a
> substractive approach. It specifies a set of options to be combined (eg.
> -march=armv7-a,armv7ve,armv8-a, with
> -mfpu=vfpv3-d16,neon,vfpv4-d16,neon-fpv4,neon-fp-armv8) using MULTILIB_OPTIONS
> and then specifies which combination should *not* be built with
> MULTILIB_EXCEPTIONS.
>
> This patch replaces that approach by an additive one: using MULTILIB_REQUIRED to
> specify the combinations we *do* want. This approach is more scalable and
> maintainable:
>
> 1) Scalability
>
> The substractive approach (MULTILIB_EXCEPTIONS) is doable today because there is
> only 3 -march and 5 -mfpu options in t-aprofile. Yet it needs already 22
> MULTILIB_EXCEPTIONS to define the set of multilib to be built. Adding new
> architecture or new mfpu would make that worse. Since we only care about a small
> number of combinations (each mfpu is used with only one march), it makes more
> sense to specify what we want. The new approach only needs 9 MULTILIB_REQUIRED
> lines.
>
> 2) Maintainability
>
> Adding one new architecture or vfp option means adding exceptions for all
> combinations which does not make sense with that option (eg. if we add mfpu=foo
> we'll have to exclude all the march we don't want to mix with foo). It forces us
> to think about all combinations involved with this new option and thinking about
> the combinations in it that we do not want. Basically we have to do the work of
> genmultilib in our mind. MULTILIB_REQUIRED on the other hand would allow us to
> just specify the combination involving that new option that we care about which
> is likely to be more obvious IMHO.
>
> Patch is in attachment. ChangeLog entry is as follows:
>
>
> *** gcc/ChangeLog ***
>
> 2016-08-01  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>
>         * config/arm/t-aprofile (MULTILIB_EXCEPTIONS): Rewrite into ...
>         (MULTILIB_REQUIRED): This by specifying multilib needing to be built
>         rather than those that should not be built.
>
>
> The output of "tree lib/gcc/arm-none-eabi/7.0.0" before and after the patch
> shows that the same set of multilib is being built.
>
> Is this ok for trunk?
>
> Best regards,
>
> Thomas