[PATCH v6] Add support for SoftFloat library on ARM (original) (raw)

Jakub Vaněk linuxtardis at gmail.com
Thu Dec 13 13:39:09 UTC 2018

Hmm, the patch still fails. I will have to redo the changes in the source tree and then reexport the patch. Editing the patch file manually wasn't a good idea.

Thanks,

Jakub

čt 13. 12. 2018 v 14:21 odesílatel Jakub Vaněk <linuxtardis at gmail.com> napsal:

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 reinterpretcast 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 reinterpretcast 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 softfloatarm.cpp. > > >> If type cast is the only reason why don't you use reinterpretcast? > > >> > > >> regards, > > >> Boris > > > I'm using memcpy there because float32t is a struct containing a > > > single uint32t 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: JVMLDFLAGSFEATURES += > > -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 > > >>> > > > >>> > >

More information about the build-dev mailing list