[PATCH, GCC/ARM 2/2, ping] Allow combination of aprofile and rmprofile multilibs

Thomas Preudhomme thomas.preudhomme@foss.arm.com
Mon Oct 24 08:07:00 GMT 2016


Best regards,


On 13/10/16 16:35, Thomas Preudhomme wrote:
> Hi ARM maintainers,
> This patchset aims at adding multilib support for R and M profile ARM
> architectures and allowing it to be built alongside multilib for A profile ARM
> architectures. This specific patch is concerned with the latter. The patch works
> by moving the bits shared by both aprofile and rmprofile multilib build
> (variable initilization as well as ISA and float ABI to build multilib for) to a
> new t-multilib file. Then, based on which profile was requested in
> --with-multilib-list option, that files includes t-aprofile and/or t-rmprofile
> where the architecture and FPU to build the multilib for are specified.
> Unfortunately the duplication of CPU to A profile architectures could not be
> avoided because substitution due to MULTILIB_MATCHES are not transitive.
> Therefore, mapping armv7-a to armv7 for rmprofile multilib build does not have
> the expected effect. Two patches were written to allow this using 2 different
> approaches but I decided against it because this is not the right solution IMO.
> See caveats below for what I believe is the correct approach.
> *** combined build caveats ***
> As the documentation in this patch warns, there is a few caveats to using a
> combined multilib build due to the way the multilib framework works.
> 1) For instance, when using only rmprofile the combination of options -mthumb
> -march=armv7 -mfpu=neon the thumb/-march=armv7 multilib but in a combined
> multilib build the default multilib would be used. This is because in the
> rmprofile build -mfpu=neon is not specified in MULTILIB_OPTION and thus the
> option is ignored when considering MULTILIB_REQUIRED entries.
> 2) Another issue is the fact that aprofile and rmprofile multilib build have
> some conflicting requirements in terms of how to map options for which no
> multilib is built to another option. (i) A first example of this is the
> difference of CPU to architecture mapping mentionned above: rmprofile multilib
> build needs A profile CPUs and architectures to be mapped down to ARMv7 so that
> one of the v7-ar multilib gets chosen in such a case but aprofile needs A
> profile architectures to stand on their own because multilibs are built for
> several architectures.
> (ii) Another example of this is that in aprofile multilib build no multilib is
> built with -mfpu=fpv5-d16 but some multilibs are built with -mfpu=fpv4-d16.
> Therefore, aprofile defines a match rule to map fpv5-d16 onto fpv4-d16. However,
> rmprofile multilib profile *does* build some multilibs with -mfpu=fpv5-d16. This
> has the consequence that when building for -mthumb -march=armv7e-m
> -mfpu=fpv5-d16 -mfloat-abi=hard the default multilib is chosen because this is
> rewritten into -mthumb -march=armv7e-m -mfpu=fpv5-d16 -mfloat-abi=hard and there
> is no multilib for that.
> Both of these issues could be handled by using MULTILIB_REUSE instead of
> MULTILIB_MATCHES but this would require a large set of rules. I believe instead
> the right approach is to create a new mechanism to inform GCC on how options can
> be down mapped _when no multilib can be found_ which would require a smaller set
> of rules and would make it explicit that the options are not equivalent. A patch
> will be posted to this effect at a later time.
> ChangeLog entry is as follows:
> *** gcc/ChangeLog ***
> 2016-10-03  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>         * config.gcc: Allow combinations of aprofile and rmprofile values for
>         --with-multilib-list.
>         * config/arm/t-multilib: New file.
>         * config/arm/t-aprofile: Remove initialization of MULTILIB_*
>         variables.  Remove setting of ISA and floating-point ABI in
>         MULTILIB_OPTIONS and MULTILIB_DIRNAMES.  Set architecture and FPU in
>         and MULTILIB_DIRNAMES respectively.  Add comment to introduce all
>         matches.  Add architecture matches for marvel-pj4 and generic-armv7-a
>         CPU options.
>         * config/arm/t-rmprofile: Likewise except for the matches changes.
>         * doc/install.texi (--with-multilib-list): Document the combination of
>         aprofile and rmprofile values and warn about pitfalls in doing that.
> Testing:
> * "tree install/lib/gcc/arm-none-eabi/7.0.0" is the same before and after the
> patchset for both aprofile and rmprofile
> * "tree install/lib/gcc/arm-none-eabi/7.0.0" is the same for aprofile,rmprofile
> and rmprofile,aprofile
> * default spec (gcc -dumpspecs) is the same for aprofile,rmprofile and
> rmprofile,aprofile
> * Difference in --print-multi-directory between aprofile or rmprofile and
> aprofile,rmprofile for all combination of ISA (ARM/Thumb), architecture, CPU,
> FPU and float ABI is as expected (best multilib for the combination is chosen),
> modulo the caveat mentionned above and the new marvel-pj4 and generic-armv7-a
> CPU to architecture mapping.
> Is this ok for master?
> Best regards,
> Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2_combine_profile_multilib.patch
Type: text/x-patch
Size: 9988 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20161024/8eb266ec/attachment.bin>

More information about the Gcc-patches mailing list