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

[Thomas Preudhomme]

Ping?

Best regards,

Thomas

On 02/11/16 10:05, Thomas Preudhomme wrote:
> Ping?
>
> Best regards,
>
> Thomas
>
> On 24/10/16 09:07, Thomas Preudhomme wrote:
>> Ping?
>>
>> Best regards,
>>
>> Thomas
>>
>> 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
>>>         MULTI_ARCH_OPTS_A and MULTI_ARCH_DIRS_A rather than MULTILIB_OPTIONS
>>>         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/20161108/e9fae22a/attachment.bin>