[PATCH] D57143: [builtins] Rounding mode support for addxf3/subxf3

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 28 16:49:44 PST 2019


efriedma added inline comments.


================
Comment at: compiler-rt/lib/builtins/arm/fp_mode.c:25
+  uint32_t fpscr;
+  __asm__ __volatile__("vmrs  %0, fpscr" : "=r" (fpscr));
+  fpscr = fpscr >> ARM_RMODE_SHIFT & ARM_RMODE_MASK;
----------------
kongyi wrote:
> MaskRay wrote:
> > MaskRay wrote:
> > > efriedma wrote:
> > > > This needs to be guarded; vmrs is only valid on targets which support VFP.  Not sure if we need to try to check that at runtime...
> > > On ARM, perhaps we can assume only `FE_TONEAREST` is available.
> > > 
> > > https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/arm/ieee754-sf.S
> > > 
> > > > Only the default rounding mode is intended for best performances.
> > For aarch64, implementing `__fegetround` in assembly also looks good to me. In musl http://git.musl-libc.org/cgit/musl/tree/src/fenv/aarch64/fenv.s
> > 
> > ```
> > .global fegetround
> > .type fegetround,%function
> > fegetround:
> > 	mrs x0, fpcr
> > 	and w0, w0, #0xc00000
> > 	ret
> > ```
> Added check for `__ARM_FP`. Fallback to default rounding if VFP is not available.
I'm a little concerned this will do something unexpected on soft-float ARM Linux (which is usually built for a target without VFP support, but often runs on a chip that actually supports it).  I guess always disabling other rounding modes is more intuitive than enabling them conditionally, though; should be fine.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57143/new/

https://reviews.llvm.org/D57143





More information about the llvm-commits mailing list