Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
On Fri, 10 Apr 2015, Hale Wang wrote: > According to the run-time ABI for ARM architecture, this function is allowed > to corrupt only the integer core registers permitted to be corrupted by the > [AAPCS] (r0-r3, ip, lr, and CPSR). So we can't just simply use the existing > GNU conversion functions to implement this function. I don't see that "only". Indeed, at the bottom of page 15 in IHI0043D, "If the FP instruction set is available, implementations of these functions may use it. Consequently, FP hardware-using code that calls one of these helper functions directly, or indirectly by calling a function with a base-standard interface, must assume that the FP parameter, result, scratch, and status registers might be altered by a call to it.". (Furthermore, the ideal result on implementations with VFP but not hardware half-precision support would be that the software conversions interact properly with hardware exceptions and rounding modes (so using FPSCR).) -- Joseph S. Myers jos...@codesourcery.com
RE: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Joseph Myers > Sent: Saturday, April 11, 2015 4:30 AM > To: Hale Wang > Cc: 'GCC Patches' > Subject: Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision > conversion functions. > > On Fri, 10 Apr 2015, Hale Wang wrote: > > > According to the run-time ABI for ARM architecture, this function is > > allowed to corrupt only the integer core registers permitted to be > > corrupted by the [AAPCS] (r0-r3, ip, lr, and CPSR). So we can't just > > simply use the existing GNU conversion functions to implement this > function. > > I don't see that "only". Indeed, at the bottom of page 15 in IHI0043D, "If the > FP instruction set is available, implementations of these functions may use it. > Consequently, FP hardware-using code that calls one of these helper > functions directly, or indirectly by calling a function with a base-standard > interface, must assume that the FP parameter, result, scratch, and status > registers might be altered by a call to it.". 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? Hale > > (Furthermore, the ideal result on implementations with VFP but not > hardware half-precision support would be that the software conversions > interact properly with hardware exceptions and rounding modes (so using > FPSCR).) > > -- > Joseph S. Myers > jos...@codesourcery.com
RE: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
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, are any special options needed at all? -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
On Mon, Apr 13, 2015 at 12:25 PM, Joseph Myers 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, are any special options needed at all? 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 ? regards Ramana > > -- > Joseph S. Myers > jos...@codesourcery.com
RE: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
> -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 > 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
Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
On Wed, Apr 22, 2015 at 9:32 AM, Hale Wang wrote: >> -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 >> 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. Or why not "conditionally" use the ``pcs'' attribute on the ARM port ? That then means you don't need options magic on top ? Ramana
RE: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision conversion functions.
> -Original Message- > From: Ramana Radhakrishnan [mailto:ramana@googlemail.com] > Sent: Wednesday, April 22, 2015 5:00 PM > To: Hale Wang > Cc: Ramana Radhakrishnan; Joseph Myers; GCC Patches > Subject: Re: [PATCH] [1/2] [ARM] [libgcc] Support RTABI half-precision > conversion functions. > > On Wed, Apr 22, 2015 at 9:32 AM, Hale Wang wrote: > >> -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 > >> 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. > > Or why not "conditionally" use the ``pcs'' attribute on the ARM port ? > That then means you don't need options magic on top ? OK. I think your suggestion can solve this problem more clearly. I will resubmit a patch later. I think we can discard this patch this time. Thanks a lot. Hale > > Ramana
