Extend bf16 #1902
Extend bf16 #1902
Conversation
Signed-off-by: Chih-Min Chao <[email protected]>
also add fxx_neg helper functions Signed-off-by: Chih-Min Chao <[email protected]>
chihminchao
force-pushed
the
extend-bf16
branch
from
a9f8b17 to
ad9238f
Compare
| return signF32UI(a.v); | ||
| } | ||
|
|
||
| bool f64_neg( float64_t a ) |
There was a problem hiding this comment.
neg is a confusing name for these functions; it sounds like a function that negates (i.e. returns -a), especially since RISC-V has pseudoinstructions named fneg that perform the negation operation. sign is a better name.
|
|
||
| bfloat16_t i32_to_bf16( int32_t a ) | ||
| { | ||
| return f32_to_bf16(i32_to_f32(a)); |
There was a problem hiding this comment.
I would like @nibrunieAtSi5's confirmation, but I believe this implementation can incorrectly double-round. You need to perform the i32 to f32 conversion under round-to-odd, then restore the rounding mode before converting to bf16.
There was a problem hiding this comment.
That sounds about right,
for example converting 0b1_0000_0001_0000_0000_0001_0000 (a.k.a. 0x1010011) from integer to BF16 going through FP32 will result in an error in RNE mode:
- 1st conversion will result in 0b1_0000_0001_0000_0000_000 (since the input is a mid-point for FP32, it is rounded to the even mantissa)
- 2nd conversion from FP32 to BF16 will round the mantissa to 0b1_0000_000 (same reason)
but in fact 0b1_0000_001 was expected but the sticky information encompassed in the round bit of the first conversion was lost
| case 0x004: // -subnormal | ||
| case 0x020: //+ sub | ||
| sub = true; | ||
| default: // +- normal |
There was a problem hiding this comment.
@nibrunieAtSi5 should review this one, since IIRC there is a special case for BF16 subnormals.
|
|
||
| float16_t ui32_to_bf16( uint32_t a ) | ||
| { | ||
| return f32_to_bf16(ui32_to_f32(a)); |
There was a problem hiding this comment.
There was a problem hiding this comment.
Looks like it's on the right track, but please address the few issues I raised, possibly in consultation with @nibrunieAtSi5.
No description provided.