[libc-commits] [PATCH] D105561: [libc] Creating a struct that captures floating point encoding and manually arranges it sequentially in memory

[Hedin García via Phabricator via libc-commits]

hedingarcia marked 2 inline comments as done.
hedingarcia added inline comments.


================
Comment at: libc/utils/FPUtil/FPBits.h:117
+      return uint16_t((valueFP & FloatProp::exponentMask) >>
+                      (FloatProp::bitWidth - 1 - FloatProp::exponentWidth));
+    }
----------------
hedingarcia wrote:
> aeubanks wrote:
> > hedingarcia wrote:
> > > aeubanks wrote:
> > > > this is very confusing, can we just use `mantissaWidth`?
> > > The reason why we cannot use mantissaWidth is because in the 80-bit long double implementation the value for that field is 63 instead of 64. An explicit bit is considered in the 63 bit as the integer part of the significand (https://en.wikipedia.org/wiki/Extended_precision ). This exception leads to that long expression in getExponent(), because with only the value of mantissaWidth the shift will still require to move one bit in order to return all the bits of the exponent.  
> > I thought that only applied to the version in LongDoubleBitsX86
> Yes, however should the same implementation in LongDoubleBitsX86.h  be kept the same even in FPBits.h?
I see what you mean now, yes since LongDoubleBitsX86.h takes care of the long double implementation, this file only should take in consideration that explicit bit. FPBits.h does not have to work around this case since it is used for single and double. Thank you for catching that detail.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105561