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

Tue Dec 6 11:35:00 GMT 2016

Ping?

*** 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.

Best regards,

Thomas

On 17/11/16 20:43, Thomas Preudhomme wrote:
> Ping?
>
> Best regards,
>
> Thomas
>
> On 08/11/16 13:36, Thomas Preudhomme wrote:
>> 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/20161206/3c26349d/attachment.bin>