> -----Original Message----- > From: Ramana Radhakrishnan [mailto:ramana....@googlemail.com] > Sent: Wednesday, April 22, 2015 3:50 PM > To: Joseph Myers > Cc: Hale Wang; GCC Patches > Subject: Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision > conversion functions. > > On Mon, Apr 13, 2015 at 12:25 PM, Joseph Myers > <jos...@codesourcery.com> wrote: > > On Mon, 13 Apr 2015, Hale Wang wrote: > > > >> Yes, you are right. It's my fault to add the "only" here. Thank you > >> to point out this. > >> Beside this, is this patch OK for you? > > > > I don't think it's a good idea for libgcc to include large pieces of > > assembly code generated by a compiler. Just compile the code with > > whatever options are needed at the time libgcc is built - possibly > > with #if conditionals to allow compiling different versions of the code.
Indeed, just compile the code with option '-mfloat-abi=soft' at the time libgcc is build which can solve this problem. > > Indeed, are any special options needed at all? > The reason is that the current GNU versions of the fp16 conversions are more efficient than the AEABI versions in this patch(and also more efficient than the code compiled with option '-mfloat-abi=soft', because no fp registers will be used to implement these functions which is allowed in the GNU versions). We provide an option so that the users can choose the version as they want(whether they want to follow the AEABI constraint or not). > > I agree and I don't think it's maintainable in the long run. From my reading > of > this thread I can't see any special options being needed. > Can we just massage it in C ? > The reason is that the implementations of these helper functions are allowed to corrupt the integer core registers permitted to be corrupted by the [AAPCS] (r0-r3, ip, lr, and CPSR). To guarantee this if we just massage it in C, as Joseph suggested, we can compile the code with whatever options are needed at the time libgcc is built. Possibly the option '-mfloat-abi=soft ' can help us to guarantee this (seems more strict than the AEABI constraint). The special option is provided so that the users can choose the version as they want(whether they want to follow the AEABI constraint or not). Because the current GNU versions of the fp16 conversions are more efficient than the AEABI versions in this patch. Best Regards, Hale > > regards > Ramana > > > > > -- > > Joseph S. Myers > > jos...@codesourcery.com
