[PATCH] D152766: AMDGPU: Use correct lowering for llvm.log2.f32
Stanislav Mekhanoshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 22 02:15:18 PDT 2023
rampitec added inline comments.
================
Comment at: llvm/docs/AMDGPUUsage.rst:963
+ half). Not implemented for double. Hardware provides
+ 1ULP accuracy for float, and 0.51ULP for half. Float
+ instruction does not natively support denormal
----------------
rampitec wrote:
> foad wrote:
> > rampitec wrote:
> > > rampitec wrote:
> > > > arsenm wrote:
> > > > > rampitec wrote:
> > > > > > Typo 0.51ULP?
> > > > > That's what the last 3 public ISA docs say
> > > > For what I know this does not make any sense. Someones finger must be mistyped. @b-sumner can you comment please?
> > > I.e. I understand 0.5ULP. This is half of a bit, when you do not known how to round it: up or down. But what is 1/100 of a bit? Is that like your computation is 100 bits more accurate, but you do not know how to round it?
> > It's when the true result is something.51 but the hardware rounds it down, or the true result is something.49 but the hardware rounds it up.
> >
> > I assume for f16 someone exhaustively tested all inputs, measured the largest error from the true result, and decided 0.51 bits was a nice neat upper bound that they could publish.
> But the representation is in binary, not in decimal. There can be no true result 0.51 decimal to have this rounding problem, it must be 0.51 of a bit. This is the definition of the ULP: 1 bit. We have 0.51 of a bit here.
I.e. anything above 0.5ULP is 1ULP to me. If your previous mantissa bit is 1 you round it up, if it is 0 you round it down, or whatever rules you have you can only change a single bit. Your 100th bit which you cannot represent doesn't matter. If you can have a single bit error in the lowest mantissa bit, this is 1ULP.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D152766/new/
https://reviews.llvm.org/D152766
More information about the llvm-commits
mailing list