[PATCH v6] Add support for SoftFloat library on ARM

[Jakub Vaněk]

Hi,

I have made a mistake when editing the patch (I forgot to change the
added line count in one header).

https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch

Thanks,

Jakub

čt 13. 12. 2018 v 14:10 odesílatel Jakub Vaněk <linuxtardis at gmail.com> napsal:
>
> Hi Boris,
>
> I have updated the patch:
> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch
>
> Now reinterpret_cast is used and the URL is present
> only in the documentation for enabling flags.
>
> I didn't expect a performance penalty, I have seen
> somewhere that compilers are nowadays good in
> seeing through this type of operation:
> https://blog.regehr.org/archives/959
>
> I tried compiling a similar code (with noinline functions)
> on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is
> optimized away even on -O0.
>
> However I agree that the reinterpret_cast way is more
> readable and conscise.
>
> Thanks,
>
> Jakub
>
> čt 13. 12. 2018 v 9:11 odesílatel Boris Ulasevich
> <boris.ulasevich at bell-sw.com> napsal:
> >
> > Hi Jakub,
> >
> > Please see comments inline.
> > And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html).
> >
> > Boris
> >
> > 12.12.2018 17:36, Jakub Vaněk пишет:
> > > Hi Erik,
> > >
> > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote:
> > >> Hi Jakub,
> > >>
> > >> I do not understand why you use memcpy in softfloat_arm.cpp.
> > >> If type cast is the only reason why don't you use reinterpret_cast?
> > >>
> > >> regards,
> > >> Boris
> > > I'm using memcpy there because float32_t is a struct containing a
> > > single uint32_t member. I think that the proper way of doing a byte-
> > > level conversion between different types (type punning) is via memcpy.
> > Do not you expect performance penalty using type conversion this way?
> > > If I used a casted pointer, this would violate the rule that I can
> > > access a memory location through a pointer of only one type.
> >
> > -fno-strict-aliasing gcc option is used to disable compiler complains on
> > this rule:
> >
> > jdk-jdk/make/hotspot/lib/JvmFeatures.gmk:  JVM_LDFLAGS_FEATURES +=
> > -fno-strict-aliasing
> >
> > > Using
> > > union for this seems to be also undefined in C++, as then I would
> > > access the value through a non-active member.
> > >
> > > Thanks,
> > >
> > > Jakub
> > >
> > >> On 10.12.2018 23:23, Jakub Vaněk wrote:
> > >>> Hi Erik,
> > >>>
> > >>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote:
> > >>>> The build changes look ok to me.
> > >>>>
> > >>>> I do think --enable-softfloat is redundant as using any of the
> > >>>> other
> > >>>> parameters would imply it to be set, but it's ok to have it
> > >>>> there.
> > >>> Thanks for the review. The motivation for this was that I was
> > >>> closely
> > >>> following how libffi is handled. The enable option was a workaround
> > >>> for
> > >>> the detection of softfloat in system paths. I don't think this is
> > >>> how
> > >>> the library is going to be used, so I removed this option.
> > >>>
> > >>> New patch can be found here:
> > >>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch
> > >>>
> > >>> Regards,
> > >>>
> > >>> Jakub
> > >>>
> > >>>> /Erik
> > >>> < raw patch at
> > >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch
> > >>>   >
> > >>>
> >