This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] sparc: remove ceil, floor, trunc sparc specific implementations


On 2016-08-02 21:01, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 01 Aug 2016 18:10:33 -0700 (PDT)
> 
> > From: Aurelien Jarno <aurelien@aurel32.net>
> > Date: Tue, 2 Aug 2016 01:59:24 +0200
> > 
> >> On 2016-08-01 14:57, David Miller wrote:
> >>> >> Aurelien, it looks like we have the same exact issue with nearbyint on
> >>> >> sparc, right?
> >>> > 
> >>> > I don't see the issue on nearbyint here. What is the issue exactly?
> >>> 
> >>> Maybe only the vis3 variant shows the problem:
> >>> 
> >>> Failure: nearbyint (sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint (-sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_downward (sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_downward (-sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_towardzero (sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_towardzero (-sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_upward (sNaN): Exception "Invalid operation" not set
> >>> Failure: nearbyint_upward (-sNaN): Exception "Invalid operation" not set
>  ...
> >> Now about the fix itself, we have to move the check before the fsr is
> >> saved and after the value has been moved to the floating point register,
> >> which is not something easy to do without breaking the whole code. One
> >> option would be to do it after loading the fsr at the end, the other one
> >> would be to use the generic version.
> > 
> > I'll look into this.
> 
> Aurelien I just tested the following and committed it to master:

Thanks!

I have finally been able to look at the fdim issue. I have tried to
compile the generic s_fdim.c without the missing test to generate
ERANGE. It appears that GCC generate very similar code on sparc32. On
sparc64 it does the same provided the file is compiled with -mvis. It
appears we compile sparc64 (and sysdeps/sparc/sparc32/sparcv9) assuming
a CPU with VIS instructions but we don't ask GCC to use them.

I therefore propose the following set of patches:
- Remove the current fdim/fdimf assembler implementation. This way this
  patch can be easily backported.
- Pass -mvis when targetting sparc64
- Pass -mvis for files in sysdeps/sparc/sparc32/sparcv9. This will also
  improve some more functions.
- Compile the generic fdim/fdimf functions with -mvis and -mvis3 in the
  multiarch directory on sparc32.

I have already started working on that, I hope to get them by tomorrow.

In general we should probably review the existing optimized assembly
code. It looks like recent versions of GCC are good at generating
optimized code, provided they are fed with the correct -mvis or -mvis3
options.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]