[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Re: [PATCH] Remove SoftFloat library dependency in arm-sflt builds
From:       David Holmes <david.holmes () oracle ! com>
Date:       2018-11-26 7:21:43
Message-ID: 9c3a5f0e-5cda-06f2-b940-6b012e077453 () oracle ! com
[Download RAW message or body]

Hi Jakub,

On 26/11/2018 1:52 am, Jakub Vaněk wrote:
> Hi,
> 
> this patch removes the workaround introduced to increase the floating
> point precision on ARM softfloat builds.
> More info about this can be found here:
> http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000610.html

In:

http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000618.html

Bob (cc'd) states:

"I did a patch in JDK8 that makes the soft-float2b library optional. 
This patch never made its way into JDK9."

Digging into that (it's non-public) what he did was to only set 
--with-sflt-lib=${PATH_TO_SFLT_LIB} if PATH_TO_SFLT_LIB was set (this 
was likely only in the closed makefiles); and it was documented in the 
SE Embedded builds readme file that you have to obtain and build the 
slft library yourself (with exact instructions on doing that).

> Currently, without addressing the workaround, the arm-sflt build fails,
> because these symbols are intended to be provided by an external
> library.
> 
> I see two ways of handling this problem:
> a) the workaround introduced to address the slightly lower precision is
> dropped. The arm-sflt build then probably won't pass the TCK.

Unless the native sflt implementation has changed, it won't pass the TCK.

> b) the workaround is extended. This includes creating a wrapper around
> a modern SoftFloat version and integrating it into the build system. On
> the other hand, this means we have to add the glue code and that the
> softfloat library has to be built separately.
> 
> I'm not sure which way is better. I hope nobody is going to do perform
> fp math on old ARM processors which would need the best precision.
> Therefore I'm sending the easier solution - to drop the workaround. I'm
> open to working on the other option, though.

I'm unclear what the requirements are regarding the TCKs. If this is not 
essential then removing the external library interface is fine. But I'd 
do that by actually changing the calls not by a simple #define that 
won't make sense to anyone in the future. And with a comment explaining 
about precision and how it can be obtained using the external library.

Otherwise we can probably open source the build instructions we 
previously provided in the SE Embedded bundle.

Cheers,
David

> Thanks,
> 
> Jakub
> 
> # HG changeset patch
> # User Jakub Vaněk <linuxtardis@gmail.com>
> # Date 1542067026 -3600
> #      Tue Nov 13 00:57:06 2018 +0100
> # Node ID 7863d8fe25d9d4e703d6650aedb223968c115e64
> # Parent  a609d549992a4d094a514a6c0f5b79443192d8bf
> Remove external softfloat library requirement for sflt builds
> 
> diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp
> b/src/hotspot/cpu/arm/assembler_arm_32.hpp
> --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp
> +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp
> @@ -1242,10 +1242,11 @@
>   
>   // Imported code from glibc soft-fp bundle for
>   // calculation accuracy improvement. See CR 6757269.
> -extern double __aeabi_fadd_glibc(float, float);
> -extern double __aeabi_fsub_glibc(float, float);
> -extern double __aeabi_dadd_glibc(double, double);
> -extern double __aeabi_dsub_glibc(double, double);
> +#define __aeabi_fadd_glibc __aeabi_fadd
> +#define __aeabi_fsub_glibc __aeabi_fsub
> +#define __aeabi_dadd_glibc __aeabi_dadd
> +#define __aeabi_dsub_glibc __aeabi_dsub
> +
>   };
>   #endif // __SOFTFP__
>   
> 
> 
> 
[prev in list] [next in list] [prev in thread] [next in thread]