FWIW, the testcases were taken from https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01026.html
Previous approach for fixing tying of fmul to fdiv can be seen in https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01971.html. As mentioned in the cover letter, this patch went for a completely different approach and does not share any code besides the testcases. Best regards, Thomas On Mon, 19 Nov 2018 at 09:57, Thomas Preudhomme <thomas.preudho...@linaro.org> wrote: > > Softfloat single precision and double precision floating-point > multiplication routines in libgcc share some code with the > floating-point division of their corresponding precision. As the code > is structured now, this leads to *all* division code being pulled in an > executable in softfloat mode even if only multiplication is > performed. > > This patch create some new LIB1ASMFUNCS macros to also build files with > just the multiplication and shared code as weak symbols. By putting > these earlier in the static library, they can then be picked up when > only multiplication is used and they are overriden by the global > definition in the existing file containing both multiplication and > division code when division is needed. > > The patch also removes changes made to the FUNC_START and ARM_FUNC_START > macros in r218124 since the intent was to put multiplication and > division code into their own section in a later patch to achieve the > same size optimization. That approach relied on specific section layout > to ensure multiplication and division were not too far from the shared > bit of code in order to the branches to be within range. Due to lack of > guarantee regarding section layout, in particular with all the > possibility of linker scripts, this approach was chosen instead. This > patch keeps the two testcases that were posted by Tony Wang (an Arm > employee at the time) on the mailing list to implement this approach > and adds a new one, hence the attribution. > > ChangeLog entries are as follows: > > *** gcc/ChangeLog *** > > 2018-11-14 Thomas Preud'homme <thomas.preudho...@linaro.org> > > * config/arm/elf.h: Update comment about condition that need to > match with libgcc/config/arm/lib1funcs.S to also include > libgcc/config/arm/t-arm. > * doc/sourcebuild.texi (output-exists, output-exists-not): Rename > subsubsection these directives are in to "Check for output files". > Move scan-symbol to that section and add to it new scan-symbol-not > directive. > > *** gcc/testsuite/ChangeLog *** > > 2018-11-16 Tony Wang <tony.w...@arm.com> > Thomas Preud'homme <thomas.preudho...@linaro.org> > > * lib/lto.exp (lto-execute): Define output_file and testname_with_flags > to same value as execname. > (scan-symbol): Move and rename to ... > * lib/gcc-dg.exp (scan-symbol-common): This. Adapt into a > helper function returning true or false if a symbol is present. > (scan-symbol): New procedure. > (scan-symbol-not): Likewise. > * gcc.target/arm/size-optimization-ieee-1.c: New testcase. > * gcc.target/arm/size-optimization-ieee-2.c: Likewise. > * gcc.target/arm/size-optimization-ieee-3.c: Likewise. > > *** libgcc/ChangeLog *** > > 2018-11-16 Thomas Preud'homme <thomas.preudho...@linaro.org> > > * /config/arm/lib1funcs.S (FUNC_START): Remove unused sp_section > parameter and corresponding code. > (ARM_FUNC_START): Likewise in both definitions. > Also update footer comment about condition that need to match with > gcc/config/arm/elf.h to also include libgcc/config/arm/t-arm. > * config/arm/ieee754-df.S (muldf3): Also build it if L_arm_muldf3 is > defined. Weakly define it in this case. > * config/arm/ieee754-sf.S (mulsf3): Likewise with L_arm_mulsf3. > * config/arm/t-elf (LIB1ASMFUNCS): Build _arm_muldf3.o and > _arm_mulsf3.o before muldiv versions if targeting Thumb-1 only. Add > comment to keep condition in sync with the one in > libgcc/config/arm/lib1funcs.S and gcc/config/arm/elf.h. > > Testing: Bootstrapped on arm-linux-gnueabihf (Arm & Thumb-2) and > testsuite shows no > regression. Also built an arm-none-eabi cross compiler targeting > soft-float which also shows no regression. In particular newly added > tests and gcc.dg/lto/20081212-1 test pass. > > Is this ok for stage3? > > Best regards, > > Thomas
