[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