FP Denorm ACT - Githubissues

riscv-admin / dev-partners

This repo is for tracking of RISC-V Development Partners Activities

3 stars 0 forks source link

FP Denorm ACT #36

Open jjscheel opened 1 year ago

jjscheel commented 1 year ago

Technical Group

Architecture Test SIG

ratification-pkg

all FP extensions

Technical Liaison

Allen Baum

Task Category

Arch Tests

Ratification Target

Legacy

Statement of Work (SOW)

Component names: D,F,Q, Zfh, Zfinx, Zdinx, Zhinx

Requirements: Add directed test cases for FP ops that generate a normalized result, but also set the underflow flag

Origin For an obscure IEEE FP reason, it is possible to generate a normalized FP result while still setting the underflow flag. This is because the underflow is set after rounding – but for some corner cases, two roundings can occur. This happens when a denormalized number , after rounding, becomes the largest denorm. When converted to a denorm format, a second rounding (if the result is odd) occurs, which can round up and overflow for some rounding modes, and it becomes normalized.

Test Details of Required Tests

For each FP op (FADD, FSUB, FMUL, FDIV, FSQRT, FMUL[N][ADD/SUB},
                             FCVT.S.D, FCVT.D.Q, FCVT.H.x
                             (any FPCVT from a longer FP format to a shorter FP format)

Choose operands that result in raw values for each FP format (before any rounding) of
   EXP = -bias, (is 127 for single, 2047 for double, etc)
   SGN= 0 and1
   MANT = all 1s & all1-1 (including hidden bit) for each FP format
   All 4 combinations of guard and sticky bits

Deliverables: Since the real requirement is generation of an internal rounded result of all 1s, which is not architecturally visible, we can’t write the coverage except to verify the output is either the smallest normalized number or the largest denorm.

Assembly language tests that meet the TestFormatSpec,
Coverage models using riscv-ctg YAML formatted schema Acceptance criteria

Acceptance Criteria:

Tests pass using the riscof framework

Projected timeframe: 3 months

SOW Signoffs: (delete those not needed)

Task group liaison sign-off
Development partner sign-off
ACT SIG sign-off (if ACT work)

Waiver

[ ] Freeze
[ ] Ratification

Pull Request Details

TBD

jjscheel commented 1 year ago

@ptprasanna, please review this SOW and ask any questions here. The text came from @allenjbaum. He will be your primary resource on this item.

We should discuss more in our next meeting.

jjscheel commented 1 year ago

Updated typos in the description section.

jjscheel commented 1 year ago

Comments from @allenjbaum via email:

I'm wondering if we should include a requirement to show that the intermediate result is in the required range (e.g. with a manual calculation). That's pretty easy for most of these on RV32 (with a hex calculator) except divide and sqrt perhaps, but more difficult with longer word lengths than hex calculators normally support.

Actually, the tricky bit (sic) is to see that guard/round bits have all 4 combinations

ptprasanna commented 1 year ago

@jjscheel and @allenjbaum, Had a detailed discussion with @anuani21 on this, looks like we do have the tests available and running on the given combination. It's just that the underflow flag which we failed to set on fcsr to acknowledge the result is a denorm, is bit of a gap in the development, which is been caught now. @anuani21 is working on it to fix this up.

jjscheel commented 1 year ago

Thanks, @ptprasanna! Please keep working with @allenjbaum and the sig-arch-test group.

allenjbaum commented 1 year ago

Note that the result that is stored is NOT a denorm ! The result at some intermediate stage could be considered to be a denorm, and then rounded up to be normalized, but the denorm flag is still set.

On Thu, Nov 2, 2023 at 9:51 PM Prasanna T @.***> wrote:

@jjscheel https://github.com/jjscheel and @allenjbaum https://github.com/allenjbaum, Had a detailed discussion with @anuani21 https://github.com/anuani21 on this, looks like we do have the tests available and running on the given combination. It's just that the underflow flag which we failed to set on fcsr to acknowledge the result is a denorm, is bit of a gap in the development, which is been caught now. @anuani21 https://github.com/anuani21 is working on it to fix this up.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1791891304, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJQZXDCG6SJ3DDSLKDDYCRZ5VAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRHA4TCMZQGQ . You are receiving this because you were mentioned.Message ID: @.***>

jjscheel commented 12 months ago

@ptprasanna, any chance on an update here?

anuani21 commented 12 months ago

@jjscheel Test generated for F,Zfh,Zfinx and Zhinx extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

Tests and coverage reports for F,Zfh,Zfinx and Zhinx are placed in the below link https://gitlab.com/ptprasanna/actreports/-/tree/main/FP_denorm?ref_type=heads

allenjbaum commented 12 months ago

Could you file a PR for this in the appropriate riscv github repo? These should include the actual additional tests (preferably just some new tests, not completely regenerated tests, which are impossible to review) and new coverage files or just point me at the PR if it's already been filed instead of to a gitlab site.

On Tue, Nov 28, 2023 at 12:34 AM anuani21 @.***> wrote:

@jjscheel https://github.com/jjscheel Test generated for F,Zfh,Zfinx and Zhinx extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

Tests and coverage reports for F,Zfh,Zfinx and Zhinx are placed in the below link

https://gitlab.com/ptprasanna/actreports/-/tree/main/FP_denorm?ref_type=heads

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1829335786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJSJG5XNXH2FYATVA5TYGWO2TAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGMZTKNZYGY . You are receiving this because you were mentioned.Message ID: @.***>

anuani21 commented 11 months ago

@allenjbaum, I am generating test case for D, Zdinx and Q extension for the given combination. Along with the coverage report for these extensions, I will raise a PR in appropriate riscv github.

allenjbaum commented 11 months ago

Thanks. I've been reviewing FP coverage overall, and have some questions about the coverage descriptions in

riscv-isac https://github.com/riscv-software-src/riscv-isac/tree/master
/riscv_isac https://github.com/riscv-software-src/riscv-isac/tree/master/riscv_isac/ fp_dataset.py Who would the right person to be to answer questions about that?

On Sun, Dec 10, 2023 at 10:19 PM anuani21 @.***> wrote:

@allenjbaum https://github.com/allenjbaum, I am generating test case for D, Zdinx and Q extension for the given combination. Along with the coverage report for these extensions, I will raise a PR in appropriate riscv github.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1849393960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJQVIEMONQRSWLBWF7DYI2QVTAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBZGM4TGOJWGA . You are receiving this because you were mentioned.Message ID: @.***>

anuani21 commented 10 months ago

@jjscheel, Test generated for D extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

I am generating test case for Zdinx and Q extension for the given combination.Along with coverage report for these extensions, I will a raise a PR in appropriate riscv github.

allenjbaum commented 10 months ago

Are you generating tests for just this cover point, or adding the coverpoint(s) to the existing ones and regenerating everything? Generating the test for just this coverpoint is preferred, as otherwise it takes a very long time

On Mon, Jan 22, 2024 at 8:12 PM anuani21 @.***> wrote:

@jjscheel https://github.com/jjscheel, Test generated for D extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

I am generating test case for Zdinx and Q extension for the given combination.Along with coverage report for these extensions, I will a raise a PR in appropriate riscv github.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905261257, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJULEVJKSW2626WBUSLYP42BRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGI3DCMRVG4 . You are receiving this because you were mentioned.Message ID: @.***>

anuani21 commented 10 months ago

Hi,

I am generating tests for just this coverpoints alone.Not added to the existing tests.

For the Q extension alone, I will need to make some changes in the IBM model for introducing flen=128 because in existing one it has a fix only for flen 32 and 64.

Regards, Anusha

On Tue, Jan 23, 2024 at 11:36 AM Allen Baum @.***> wrote:

Are you generating tests for just this cover point, or adding the coverpoint(s) to the existing ones and regenerating everything? Generating the test for just this coverpoint is preferred, as otherwise it takes a very long time

On Mon, Jan 22, 2024 at 8:12 PM anuani21 @.***> wrote:

@jjscheel https://github.com/jjscheel, Test generated for D extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

I am generating test case for Zdinx and Q extension for the given combination.Along with coverage report for these extensions, I will a raise a PR in appropriate riscv github.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905261257>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJULEVJKSW2626WBUSLYP42BRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGI3DCMRVG4>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905350016, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3G6FFZI62QYORSTFMD2F7DYP5HPLAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGM2TAMBRGY . You are receiving this because you were mentioned.Message ID: @.***>

allenjbaum commented 10 months ago

great! I would make Q-extension lower priority than other work though (I assume there is lots of other work!)

On Mon, Jan 22, 2024 at 10:49 PM anuani21 @.***> wrote:

Hi,

I am generating tests for just this coverpoints alone.Not added to the existing tests.

For the Q extension alone, I will need to make some changes in the IBM model for introducing flen=128 because in existing one it has a fix only for flen 32 and 64.

Regards, Anusha

On Tue, Jan 23, 2024 at 11:36 AM Allen Baum @.***> wrote:

Are you generating tests for just this cover point, or adding the coverpoint(s) to the existing ones and regenerating everything? Generating the test for just this coverpoint is preferred, as otherwise it takes a very long time

On Mon, Jan 22, 2024 at 8:12 PM anuani21 @.***> wrote:

@jjscheel https://github.com/jjscheel, Test generated for D extensions and the execution is successful.Generated test case will produce a normalized result and also set an underflow flag.

I am generating test case for Zdinx and Q extension for the given combination.Along with coverage report for these extensions, I will a raise a PR in appropriate riscv github.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905261257>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJULEVJKSW2626WBUSLYP42BRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGI3DCMRVG4>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905350016>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/A3G6FFZI62QYORSTFMD2F7DYP5HPLAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGM2TAMBRGY>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-1905388464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTZX2J3S6C3DITTR3LYP5MPLAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGM4DQNBWGQ . You are receiving this because you were mentioned.Message ID: @.***>

anuani21 commented 9 months ago

@jjscheel, Here are the updates from IITM,

Zdinx- Three operand instructions like (fmadd,fmsub,fnmadd,fnmsub) test generated but few coverpoints are not met up.I am fixing this issue. Q extension- yet to start the test.

jjscheel commented 9 months ago

@anuani21, I have set the state of the project to "Planning". I'd appreciate some outlook as to when the work will be done and confirmation that this is a "Medium" sized project (3-6 months of work).

anuani21 commented 8 months ago

No progress made since last Call. Was busy on Debug ACT for Native Triggers.

anuani21 commented 7 months ago

No progress made since last Call. Was busy on Debug ACT for Native Triggers.

anuani21 commented 2 months ago

No progress made since last Call. Was busy on Debug ACT for Native Triggers.

jjscheel commented 2 months ago

Thanks. Understand.

anuani21 commented 1 month ago

@jjscheel,

Updates from IITM,

1.Zdinx extension - Few instructions are pending.

Q-extension - yet to start the test.

We will restart the work by this week.

davidharrishmc commented 1 month ago

I see a directory of fadd tests that say "underflow flag set". Do any of these cases actually set the underflow flag? The ones I spot checked in fadd_b3 are of the form a - a, which produces an exact 0 result.

https://gitlab.com/ptprasanna/actreports/-/tree/main/FP_denorm/RV32F-denorm/fadd/RV32F-fadd-all?ref_type=heads

I'm having trouble thinking of a specific floating-point addition that would set the underflow flag. This only happens when the (possibly intermediate) result is subnormal and the result is inexact. All the addition operations I can think of that produce subnormal results are exact.

I'm confident fsqrt can't set the underflow flag because the result is never subnormal.

According to the RISC-V unprivileged spec, fadd/fsub/fsqrt never set the underflow flag.

I agree that mul, div, and convert operations can set the underflow flag and have the interesting corner case of doing so even when the final result is the minimum normalized number.

davidharrishmc commented 1 month ago

I’m also concerned that the wrong convert test cases are being generated in https://gitlab.com/ptprasanna/actreports/-/tree/main/FP_denorm?ref_type=heads

I see RV32F/fcvt.{w/wu}.s and RV32Zfh-denorm/fcvt.{w/wu}.h and RV64D-denorm/{fcvt.{l/lu}.d, none of which should produce underflow flag per the RISC-V spec Tables 19-22. I don’t see any of the converts that should be able to set an underflow flag.

jordancarlin commented 1 month ago

Additionally, based on the Sail log, it seems that something might have gone wrong in the test generation. Looking at the RV32F fadd_b3 test suite, the first test case results in the following instructions being run by the Sail model:

mem[X,0x80000114] -> 0xAF87
mem[X,0x80000116] -> 0x0001
[74] [M]: 0x80000114 (0x0001AF87) flw ft11, 0(gp)
mem[R,0x80010010] -> 0x7F222105
f31 <- 0xFFFFFFFF7F222105

mem[X,0x80000118] -> 0xAF07
mem[X,0x8000011A] -> 0x0041
[75] [M]: 0x80000118 (0x0041AF07) flw ft10, 4(gp)
mem[R,0x80010014] -> 0xFF222105
f30 <- 0xFFFFFFFFFF222105

mem[X,0x8000011C] -> 0x0113
mem[X,0x8000011E] -> 0x0020
[76] [M]: 0x8000011C (0x00200113) addi sp, zero, 2
x2 <- 0x00000002

mem[X,0x80000120] -> 0x1073
mem[X,0x80000122] -> 0x0031
[77] [M]: 0x80000120 (0x00311073) csrrw zero, fcsr, sp
CSR fcsr -> 0x00000000
CSR fcsr <- 0x00000002 (input: 0x00000002)

mem[X,0x80000124] -> 0xFFD3
mem[X,0x80000126] -> 0x01EF
[78] [M]: 0x80000124 (0x01EFFFD3) fadd.s ft11, ft11, ft10, dyn
f31 <- 0xFFFFFFFF00000000

mem[X,0x80000128] -> 0x2273
mem[X,0x8000012A] -> 0x0030
[79] [M]: 0x80000128 (0x00302273) csrrs tp, fcsr, zero
CSR fcsr -> 0x00000002
x4 <- 0x00000002

mem[X,0x8000012C] -> 0xA027
mem[X,0x8000012E] -> 0x01F0
[80] [M]: 0x8000012C (0x01F0A027) fsw ft11, 0(ra)
mem[0x80012514] <- 0x00000000

mem[X,0x80000130] -> 0xA223
mem[X,0x80000132] -> 0x0040
[81] [M]: 0x80000130 (0x0040A223) sw tp, 4(ra)
mem[0x80012518] <- 0x00000002

Sail log

This seems to be writing 0x02 to fcsr(which corresponds to the underflow bit) before the actual fadd.s operation. Since the floating point flags are sticky, this will persist until it is cleared. It is not cleared before the fadd.s operation, so the underflow flag will appear set when it is checked after the operation even if the fadd.s does not set it. Instead of setting fcsr to 0x02, it probably needs to be cleared to 0x0 before each test to ensure previous results do not mask the flags.

allenjbaum commented 1 month ago

Yes, that is correct. It should be csrrs, not csrrw.

On Tue, Oct 15, 2024 at 11:01 AM Jordan Carlin @.***> wrote:

Additionally, based on the Sail log, it seems that something might have gone wrong in the test generation. Looking at the RV32F fadd_b3 test suite, the first test case results in the following instructions being run by the Sail model:

mem[X,0x80000114] -> 0xAF87 mem[X,0x80000116] -> 0x0001

mem[R,0x80010010] -> 0x7F222105 f31 <- 0xFFFFFFFF7F222105

mem[X,0x80000118] -> 0xAF07 mem[X,0x8000011A] -> 0x0041

mem[R,0x80010014] -> 0xFF222105 f30 <- 0xFFFFFFFFFF222105

mem[X,0x8000011C] -> 0x0113 mem[X,0x8000011E] -> 0x0020 [76] [M]: 0x8000011C (0x00200113) addi sp, zero, 2 x2 <- 0x00000002

mem[X,0x80000120] -> 0x1073 mem[X,0x80000122] -> 0x0031 [77] [M]: 0x80000120 (0x00311073) csrrw zero, fcsr, sp CSR fcsr -> 0x00000000 CSR fcsr <- 0x00000002 (input: 0x00000002)

mem[X,0x80000124] -> 0xFFD3 mem[X,0x80000126] -> 0x01EF [78] [M]: 0x80000124 (0x01EFFFD3) fadd.s ft11, ft11, ft10, dyn f31 <- 0xFFFFFFFF00000000

mem[X,0x80000128] -> 0x2273 mem[X,0x8000012A] -> 0x0030 [79] [M]: 0x80000128 (0x00302273) csrrs tp, fcsr, zero CSR fcsr -> 0x00000002 x4 <- 0x00000002

mem[X,0x8000012C] -> 0xA027 mem[X,0x8000012E] -> 0x01F0

mem[0x80012514] <- 0x00000000

mem[X,0x80000130] -> 0xA223 mem[X,0x80000132] -> 0x0040

mem[0x80012518] <- 0x00000002

Sail log https://gitlab.com/ptprasanna/actreports/-/blob/main/FP_denorm/RV32F-denorm/fadd/work-RV32F-fadd-all/fadd_b3-01.S/fadd_b3-01.log?ref_type=heads

This seems to be writing 0x02 to fcsr(which corresponds to the underflow bit) before the actual fadd.s operation. Since the floating point flags are sticky, this will persist until it is cleared. It is not cleared before the fadd.s operation, so the underflow flag will appear set when it is checked after the operation even if the fadd.s does not set it. Instead of setting fcsr to 0x02, it probably needs to be cleared to 0x0 before each test to ensure previous results do not mask the flags.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414675323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVBBI6ATZ5HQT6NNYTZ3VKA3AVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUGY3TKMZSGM . You are receiving this because you were mentioned.Message ID: @.***>

allenjbaum commented 1 month ago

Doesn't the underflow exception flag get set whenever the result <MinNorm (exponent=0 & mantissa!=0, so any denorm result)? This could happen if you subtract a denorm from MinNorm, for example. (or add a negative denorm, or subtract 2 numbers very close to MinNorm to produce a subnorm. The corner case is producing a result just under MinNorm that gets rounded up to be MinNorm - the underflow flag does get set even though the final result is normalized.

I don't see how it can happen with sqrt, since the result will always be closer to 1 then the input argument (assuming it is >0)

On Tue, Oct 15, 2024 at 10:45 AM David Harris @.***> wrote:

I’m also concerned that the wrong convert test cases are being generated in

https://gitlab.com/ptprasanna/actreports/-/tree/main/FP_denorm?ref_type=heads

I see RV32F/fcvt.{w/wu}.s and RV32Zfh-denorm/fcvt.{w/wu}.h and RV64D-denorm/{fcvt.{l/lu}.d, none of which should produce underflow flag per the RISC-V spec Tables 19-22. I don’t see any of the converts that should be able to set an underflow flag.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414644649, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJSX6QHLF3CQKGYXN5TZ3VICPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUGY2DINRUHE . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

@allenjbaum do you mean it should be csrrc, not csrrs or csrsw?

davidharrishmc commented 1 month ago

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

allenjbaum commented 1 month ago

Well, csrrw is what isn't working, and csrrs would have the same effect. csrrc would cause the underflow flag to be cleared, and that's what you want to would do you're testing that underflow is set by the instruction. It would be better to just clear fcsr (so csrrw zero, fcsr, zero and remove the unnecessary addi, sp,2) on the other hand

On Tue, Oct 15, 2024 at 11:13 AM David Harris @.***> wrote:

@allenjbaum https://github.com/allenjbaum do you mean it should be csrrc, not csrrs or csrsw?

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414697250, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTQRK7L2DS2S5MRFA3Z3VLLVAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUGY4TOMRVGA . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

I would suggest csrw fflags, x0

This will clear all the flags, as you suggest, without impacting the rounding mode.

But implementation details aside, does anyone believe that fadd should raise the underflow flag, and if so, could you give a specific pair of inputs that should do so? @anuani21 can you describe the theory of operation about how the inputs were chosen in the test cases and whether you believe any of the test cases are raising the underflow?

allenjbaum commented 1 month ago

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4. You are receiving this because you commented.

allenjbaum commented 1 month ago

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU . You are receiving this because you were mentioned.Message ID: @.***>

allenjbaum commented 1 month ago

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4. You are receiving this because you commented.

allenjbaum commented 1 month ago

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

riscv-arch-test already has substantial coverage of every instruction producing normalized results, and producing subnormal results, and I recall its signature contains all of the flags for all of these situations.

The coverage hole I think we’re talking about is an instruction that produces an intermediate result that is subnormal and then gets rounded up to the smallest normal number. This should set the underflow flag. The TestFloat test cases have this corner case and I believe riscv-arch-test did not. I think that’s what this effort is trying to fix. I think you and I and the bug fix are all on the same page. I don’t think we need more coverage of cases that produce a normal result and don’t set the underflow flag, or of cases that do produce an inexact subnormal result and do set the underflow flag. I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer.

As I think about the root of the problem, I suspect the IBM testcases really did check this situation, because it is a well-known corner in the floating-point world. However, these testcases are mediated through riscv_isac/fp_dataset.py, which attempts to generate inputs that satisfy certain output behavior goals. There could be any number of subtle rounding issues or other numerical issues that cause fp_dataset.py to incorrectly produce inputs that don’t truly cover the corners. As the Wally team was looking at quads this year, we were nervous about such issues, giving the false impression of covering all the IBM corners without actually doing so, especially because trying to work on quads in Python likely makes substantial rounding errors when they actually are computed as doubles.
If numerical issues is the root cause of the underflow flag missing corner, then there’s no easy way to know if any of the other IBM corners aren’t being hit.

I’ll be at the summit next week, and perhaps we can get to a common understanding interactively.

David

On Oct 15, 2024, at 10:38 PM, Allen Baum @.***> wrote:///

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415778753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA34QQB4A4JKHTY7NKHDZ3X3WFAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVG43TQNZVGM. You are receiving this because you commented.

allenjbaum commented 1 month ago

I am still confused. We seem to be agreeing on the coverage hole - but then you say

"I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer."

Except the case that was found was fadd.. That is the root of my concern.

On Wed, Oct 16, 2024 at 6:18 AM David Harris @.***> wrote:

riscv-arch-test already has substantial coverage of every instruction producing normalized results, and producing subnormal results, and I recall its signature contains all of the flags for all of these situations.

The coverage hole I think we’re talking about is an instruction that produces an intermediate result that is subnormal and then gets rounded up to the smallest normal number. This should set the underflow flag. The TestFloat test cases have this corner case and I believe riscv-arch-test did not. I think that’s what this effort is trying to fix. I think you and I and the bug fix are all on the same page. I don’t think we need more coverage of cases that produce a normal result and don’t set the underflow flag, or of cases that do produce an inexact subnormal result and do set the underflow flag. I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer.

As I think about the root of the problem, I suspect the IBM testcases really did check this situation, because it is a well-known corner in the floating-point world. However, these testcases are mediated through riscv_isac/fp_dataset.py, which attempts to generate inputs that satisfy certain output behavior goals. There could be any number of subtle rounding issues or other numerical issues that cause fp_dataset.py to incorrectly produce inputs that don’t truly cover the corners. As the Wally team was looking at quads this year, we were nervous about such issues, giving the false impression of covering all the IBM corners without actually doing so, especially because trying to work on quads in Python likely makes substantial rounding errors when they actually are computed as doubles. If numerical issues is the root cause of the underflow flag missing corner, then there’s no easy way to know if any of the other IBM corners aren’t being hit.

I’ll be at the summit next week, and perhaps we can get to a common understanding interactively.

David

On Oct 15, 2024, at 10:38 PM, Allen Baum @.***> wrote:///

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415778753>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA34QQB4A4JKHTY7NKHDZ3X3WFAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVG43TQNZVGM>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416818978, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUXOROUQN36SK6O35TZ3ZRTXAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHAYTQOJXHA . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

"Except the case that was found was fadd.”

What’s your evidence that fadd is missing a testcase that should set underflow?

I think this tracks back to Issue #390, which suggests the problem was found in the wild for fdiv. It doesn’t say fadd is missing a corner case.

https://github.com/riscv-non-isa/riscv-arch-test/issues/390

If you think fadd is missing a testcase in which the result is the smallest normalized number (0x00800000) and the underflow flag should be set, could you state what two inputs should produce that outcome?

David

On Oct 16, 2024, at 7:15 AM, Allen Baum @.***> wrote:

I am still confused. We seem to be agreeing on the coverage hole - but then you say

"I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer."

Except the case that was found was fadd.. That is the root of my concern.

On Wed, Oct 16, 2024 at 6:18 AM David Harris @.***> wrote:

riscv-arch-test already has substantial coverage of every instruction producing normalized results, and producing subnormal results, and I recall its signature contains all of the flags for all of these situations.

The coverage hole I think we’re talking about is an instruction that produces an intermediate result that is subnormal and then gets rounded up to the smallest normal number. This should set the underflow flag. The TestFloat test cases have this corner case and I believe riscv-arch-test did not. I think that’s what this effort is trying to fix. I think you and I and the bug fix are all on the same page. I don’t think we need more coverage of cases that produce a normal result and don’t set the underflow flag, or of cases that do produce an inexact subnormal result and do set the underflow flag. I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer.

As I think about the root of the problem, I suspect the IBM testcases really did check this situation, because it is a well-known corner in the floating-point world. However, these testcases are mediated through riscv_isac/fp_dataset.py, which attempts to generate inputs that satisfy certain output behavior goals. There could be any number of subtle rounding issues or other numerical issues that cause fp_dataset.py to incorrectly produce inputs that don’t truly cover the corners. As the Wally team was looking at quads this year, we were nervous about such issues, giving the false impression of covering all the IBM corners without actually doing so, especially because trying to work on quads in Python likely makes substantial rounding errors when they actually are computed as doubles. If numerical issues is the root cause of the underflow flag missing corner, then there’s no easy way to know if any of the other IBM corners aren’t being hit.

I’ll be at the summit next week, and perhaps we can get to a common understanding interactively.

David

On Oct 15, 2024, at 10:38 PM, Allen Baum @.***> wrote:///

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415778753>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA34QQB4A4JKHTY7NKHDZ3X3WFAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVG43TQNZVGM>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416818978, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUXOROUQN36SK6O35TZ3ZRTXAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHAYTQOJXHA . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416975519, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA37S6JJNVRDCWABGA43Z3ZYIBAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHE3TKNJRHE. You are receiving this because you commented.

allenjbaum commented 1 month ago

Ah, maybe I'm misremembering - but fadd of minNorm , -MaxDenorm (or MaxDenorm/2 or MaxDenorm/4 etc) with rounding should round up to minNorm and set underflow, shouldn't it?

On Wed, Oct 16, 2024 at 7:32 AM David Harris @.***> wrote:

"Except the case that was found was fadd.”

What’s your evidence that fadd is missing a testcase that should set underflow?

I think this tracks back to Issue #390, which suggests the problem was found in the wild for fdiv. It doesn’t say fadd is missing a corner case.

https://github.com/riscv-non-isa/riscv-arch-test/issues/390

If you think fadd is missing a testcase in which the result is the smallest normalized number (0x00800000) and the underflow flag should be set, could you state what two inputs should produce that outcome?

David

On Oct 16, 2024, at 7:15 AM, Allen Baum @.***> wrote:

I am still confused. We seem to be agreeing on the coverage hole - but then you say

"I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer."

Except the case that was found was fadd.. That is the root of my concern.

On Wed, Oct 16, 2024 at 6:18 AM David Harris @.***> wrote:

riscv-arch-test already has substantial coverage of every instruction producing normalized results, and producing subnormal results, and I recall its signature contains all of the flags for all of these situations.

The coverage hole I think we’re talking about is an instruction that produces an intermediate result that is subnormal and then gets rounded up to the smallest normal number. This should set the underflow flag. The TestFloat test cases have this corner case and I believe riscv-arch-test did not. I think that’s what this effort is trying to fix. I think you and I and the bug fix are all on the same page. I don’t think we need more coverage of cases that produce a normal result and don’t set the underflow flag, or of cases that do produce an inexact subnormal result and do set the underflow flag. I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer.

As I think about the root of the problem, I suspect the IBM testcases really did check this situation, because it is a well-known corner in the floating-point world. However, these testcases are mediated through riscv_isac/fp_dataset.py, which attempts to generate inputs that satisfy certain output behavior goals. There could be any number of subtle rounding issues or other numerical issues that cause fp_dataset.py to incorrectly produce inputs that don’t truly cover the corners. As the Wally team was looking at quads this year, we were nervous about such issues, giving the false impression of covering all the IBM corners without actually doing so, especially because trying to work on quads in Python likely makes substantial rounding errors when they actually are computed as doubles. If numerical issues is the root cause of the underflow flag missing corner, then there’s no easy way to know if any of the other IBM corners aren’t being hit.

I’ll be at the summit next week, and perhaps we can get to a common understanding interactively.

David

On Oct 15, 2024, at 10:38 PM, Allen Baum @.***> wrote:///

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415778753>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA34QQB4A4JKHTY7NKHDZ3X3WFAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVG43TQNZVGM>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416818978>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJUXOROUQN36SK6O35TZ3ZRTXAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHAYTQOJXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416975519>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA37S6JJNVRDCWABGA43Z3ZYIBAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHE3TKNJRHE>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2417021863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTL3T4DP5VLH3I6SKLZ3Z2IZAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJXGAZDCOBWGM . You are receiving this because you were mentioned.Message ID: @.***>

davidharrishmc commented 1 month ago

minNorm = 0x00800000 = 1.0 x 2^-126 maxDenorm = 0x00400000 = 0.1 x 2^-126 maxDenorm/2 = 0x00200000 = 0.01 x 2^-126

minNorm -maxDenorm = 1.0 x 2^-126 - 0.1 x 2^-126 = 0.1 x 2^-126, which is exact and does not take rounding. It produces an answer 0x00400000, which is subnormal but exact, so it doesn’t set any flags.

minNorm - maxDenorm = 1.0 x 2^-126 - 0.01 x 2^-126 = 0.11 x 2^-126 = 0x00600000, which is also subnormal, exact, and doesn’t set any flags.

However, 00FFFFFF * 3F000000 = 1.111111…11 x 2^-126 x (1/2) = 0.11111…111 x 2^-126. This is not exactly representable. If rounded up, it gives 1.0 x 2^-126, which is minNorm. The answer is inexact, and underflows because the intermediate result is subnormal.

On Oct 16, 2024, at 8:37 AM, Allen Baum @.***> wrote:

Ah, maybe I'm misremembering - but fadd of minNorm , -MaxDenorm (or MaxDenorm/2 or MaxDenorm/4 etc) with rounding should round up to minNorm and set underflow, shouldn't it?

On Wed, Oct 16, 2024 at 7:32 AM David Harris @.***> wrote:

"Except the case that was found was fadd.”

What’s your evidence that fadd is missing a testcase that should set underflow?

I think this tracks back to Issue #390, which suggests the problem was found in the wild for fdiv. It doesn’t say fadd is missing a corner case.

https://github.com/riscv-non-isa/riscv-arch-test/issues/390

If you think fadd is missing a testcase in which the result is the smallest normalized number (0x00800000) and the underflow flag should be set, could you state what two inputs should produce that outcome?

David

On Oct 16, 2024, at 7:15 AM, Allen Baum @.***> wrote:

I am still confused. We seem to be agreeing on the coverage hole - but then you say

"I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer."

Except the case that was found was fadd.. That is the root of my concern.

On Wed, Oct 16, 2024 at 6:18 AM David Harris @.***> wrote:

riscv-arch-test already has substantial coverage of every instruction producing normalized results, and producing subnormal results, and I recall its signature contains all of the flags for all of these situations.

The coverage hole I think we’re talking about is an instruction that produces an intermediate result that is subnormal and then gets rounded up to the smallest normal number. This should set the underflow flag. The TestFloat test cases have this corner case and I believe riscv-arch-test did not. I think that’s what this effort is trying to fix. I think you and I and the bug fix are all on the same page. I don’t think we need more coverage of cases that produce a normal result and don’t set the underflow flag, or of cases that do produce an inexact subnormal result and do set the underflow flag. I think we just need cases that produce the smallest normal result and nevertheless set the underflow flag. Such cases only exist for certain instructions, which I believe may be fmul, fdiv, fma*, and fcvt.shorter.longer.

As I think about the root of the problem, I suspect the IBM testcases really did check this situation, because it is a well-known corner in the floating-point world. However, these testcases are mediated through riscv_isac/fp_dataset.py, which attempts to generate inputs that satisfy certain output behavior goals. There could be any number of subtle rounding issues or other numerical issues that cause fp_dataset.py to incorrectly produce inputs that don’t truly cover the corners. As the Wally team was looking at quads this year, we were nervous about such issues, giving the false impression of covering all the IBM corners without actually doing so, especially because trying to work on quads in Python likely makes substantial rounding errors when they actually are computed as doubles. If numerical issues is the root cause of the underflow flag missing corner, then there’s no easy way to know if any of the other IBM corners aren’t being hit.

I’ll be at the summit next week, and perhaps we can get to a common understanding interactively.

David

On Oct 15, 2024, at 10:38 PM, Allen Baum @.***> wrote:///

I am more concerned that the bug report was that underflow was not being generated - and that it should be (and John Hauser agreed), while you're saying the opposite. We need to get to the bottom of that. Regardless of that, we still need tests for those corner cases because....they're corner cases, and we should be testing for that..

On Tue, Oct 15, 2024 at 6:03 PM David Harris @.***> wrote:

It’s possible the Wally team was the one that sent the bug report about underflow. We certainly did a lot of work to get this case correct. The TestFloat suite helped us uncover some corner cases that weren’t in riscv-arch-test.

I know that underflow can happen in fmul,f div, fma, and fcvt. There’s evidence that it shouldn’t happen in fadd or fsub, and it certainly shouldn’t happen in fsqrt or conversions involving integers.

I’m not quite sure how the tests in this archive were generated, but luckly Jordan noticed this discussion. I’m guessing there was a typo of csrs instead of csrc, causing the underflow flag to get set and making it appear that tests were hitting underflow coverage on fadd and elsewhere, and leading to a lot of work producing test cases that shouldn’t set the underflow flag but appear to do so anyway.

Is @anuani21 the tech lead here, and knowledgeable about floating-point corner cases and how the tests and reports are generated? I would suggest fixing the csrs issue, then seeing which instructions produce underflow, and if it is easy, writing the missing fcvt cases. Then, if the instructions that the RISC-V spec Tables 19-22 say don't cause underflow (fadd/sub/sqrt, and conversions to/from int) don’t do underfow in the tests either, I think those tests could be dropped.

I’d be happy to join in a design review if it is helpful, preferably after getting new results without csrs.

David

On Oct 15, 2024, at 4:45 PM, Allen Baum @.***> wrote:

Having said all that: this corner case does need to be added to all the FP tests, (hopefully without regenerating all tets)

On Tue, Oct 15, 2024 at 4:43 PM Allen Baum @.***> wrote:

Hmm, does that mean we have a serious problem? Tinyness is detected after rounding, according to the spec. That means that underflow should not be set in the specific case I mentioned (result was denorm, but was normalized after rounding) Someone sent a bug report that it wasn't being set and should be, and I asked John Hauser, and he agreed that it should have been set. But you're saying the opposite - it should never be set

On Tue, Oct 15, 2024 at 12:20 PM David Harris @.***> wrote:

When a subnormal result is exact, the underflow flag is not set. "If the rounded result is exact, no flag is raised “

Here’s the way I describe it in my (upcoming) book:

Underflow ● If the result is tiny and a loss of accuracy occurs. A result is considered tiny when it is subnormal (|result| < 2^(emin)). A loss of accuracy occurs when the Inexact flag is set, which indicates that the answer differs from what would have occurred with unbounded precision. The IEEE 754 specification has an ambiguity that tininess may be detected either before rounding or after rounding to an intermediate result; not all implementations set this flag in the same way. RISC-V detects tininess after rounding the exact answer to the intermediate result with bounded precision but unlimited exponent range. Note that underflow is signaled when a very small result is rounded to zero, but not when the exact result is zero.

Underflow is the most subtle of the flags. While underflow is intuitively associated with subnormal results, the Underflow flag is not raised if the subnormal result is exact. Moreover, it is also raised even when the final answer is zero or the smallest normalized number 2emin, if the intermediate result is tiny. Underflow warns the programmer of risk of inaccuracy related to tiny, inexact results. … Recall that underflow depends on tininess, which is computed from the intermediate result. A tiny intermediate result can be detected from the rounded result using two cases:

Case A: The intermediate result is tiny if the rounded result is tiny. The rounded result is tiny if the final exponent is smaller than the smallest normalized number.

Case B: The intermediate result is also tiny if the rounded result is a normal number, the normalized result was subnormal, and the rounding would not push the intermediate result up to the smallest normalized value. This case only occurs when the rounded result is rounded up from the largest subnormal number 0.1111… × 2emin to the smallest normalized number 1.0 × 2emin. To detect this, check the final exponent and the exponent before rounding . Figure F.36shows the subnormal result before rounding, which is left-shifted by 1 to form an intermediate result before rounding.

0.1111 1111 11GRT × 2emin Subnormal result before rounding 1.1111 1111 1GRT × 2emin-1 Intermediate result before rounding Figure <>F.36 Determining if the intermediate result is tiny

The intermediate results is tiny if either Case A or Case B applies. The Underflow flag is raised if the intermediate result is tiny and the result is Inexact.

David

On Oct 15, 2024, at 12:05 PM, Allen Baum @.***> wrote:

These are really (sticky) status flags, but the spec describes them as Floating-Point Accrued Exceptions., which is why I used that wording. This issue came up because there was an implementation that did not set the underflow flag, and softfloat did. That was the weird rounding from denorm to norm case, so that is definitely one that should set underflow.

I believe this meets the criteria for inexact and underflow, but what happens if it is exact? (so didn't round and set denorm)

On Tue, Oct 15, 2024 at 11:17 AM David Harris @.***> wrote:

The flags are subtle. In a system with floating-point exceptions (such as x86), the underflow exception is raised for tiny results. However, the underflow flag is only raised for tiny results that are inexact. RISC-V has an underflow flag but no underflow exception.

See the IEEE 754-2019 spec at Section 7.5: In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414705478>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJXFL6ZR24LRCCSKCUTZ3VL2RAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG4YDKNBXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414798777>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA3YX3BVJLMTQFHYBNOTZ3VRRNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUG44TQNZXG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2414824865>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJVPPY6DVM6BF6YIMGTZ3VTHRAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJUHAZDIOBWGU>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415353107>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA36BA7SJ3DC5KWMM2NTZ3WSLNAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGM2TGMJQG4>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415455599>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AHPXVJUIUKWUWFQYFR4GFJDZ3W3NPAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVGQ2TKNJZHE>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2415778753>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AR4AA34QQB4A4JKHTY7NKHDZ3X3WFAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJVG43TQNZVGM>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416818978>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJUXOROUQN36SK6O35TZ3ZRTXAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHAYTQOJXHA>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2416975519>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AR4AA37S6JJNVRDCWABGA43Z3ZYIBAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWHE3TKNJRHE>.

You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2417021863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTL3T4DP5VLH3I6SKLZ3Z2IZAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJXGAZDCOBWGM . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2417202236, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA34YL2IT7TXFB6ZLZS3Z32B5BAVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJXGIYDEMRTGY. You are receiving this because you commented.

allenjbaum commented 1 month ago

Um, maxDenorm should be 0.111111...111 x 2^-126. The interesting cases are minNorm - minDenorm == maxDenorm, or minNorm - maxDenorm == minDenorm and indeed those are both exact. I keep forgetting that underflow isn't simply the intermediate result being denormalized, but being inexact AND being denormalized. That condition can't occur for add/sub because the smaller number would need to be shifted and lose a bit off the end, but the mantissas for minNorm and Denorm (or both Denorm) are aligned, so that can't happen.

OK, I've wasted enough of your time then, and agree: we should still test the above 2 cases, but shouldn't expect underflow, and we do need to test this underflow condition for fmul/fdiv/fma/fcvt. On Wed, Oct 16, 2024 at 11:10 AM David Harris @.***> wrote:

minNorm = 0x00800000 = 1.0 x 2^-126 maxDenorm = 0x00400000 = 0.1 x 2^-126 maxDenorm/2 = 0x00200000 = 0.01 x 2^-126

minNorm -maxDenorm = 1.0 x 2^-126 - 0.1 x 2^-126 = 0.1 x 2^-126, which is exact and does not take rounding. It produces an answer 0x00400000, which is subnormal but exact, so it doesn’t set any flags.

minNorm - maxDenorm = 1.0 x 2^-126 - 0.01 x 2^-126 = 0.11 x 2^-126 = 0x00600000, which is also subnormal, exact, and doesn’t set any flags.

However, 00FFFFFF * 3F000000 = 1.111111…11 x 2^-126 x (1/2) = 0.11111…111 x 2^-126. This is not exactly representable. If rounded up, it gives 1.0 x 2^-126, which is minNorm. The answer is inexact, and underflows because the intermediate result is subnormal.

Message ID: @.***>

anuani21 commented 3 weeks ago

@jjscheel,

As per Allen and David discussion, I need to do some changes in the test in all FP extensions.Probably, I will raise a PR by next week.

allenjbaum commented 3 weeks ago

Ken Dockser wrote the wording in the spec, and just sent me some examples to make it very clear what is going on. From the spec:

The IEEE-defined underflow exception requires that a result be inexact and tiny, where tininess can be

detected before or after rounding. In RISC-V, tininess is detected after rounding.

It is important to note that the detection of tininess after rounding requires its own rounding that is different from the final result rounding. This tininess detection requires rounding as if the exponent were unbounded. This means that the input to the rounder is always a normal number.

This is different from the final result rounding where the input to the rounder is a subnormal number when the value is too

small to be represented as a normal number in the target format.

The two different roundings can result in underflow being signalled for results that are rounded back to the normal range.

As is defined in '754, under default exception handling, underflow is only signalled when the result is tiny and inexact.

In such a case, both the underflow and inexact flags are raised.

So, given a tiny-check with a "tiny-rounding" stage which normalizes (shift denorms so mantissa MSB=1) before the rounding, followed "result-rounding" stage which rounds the unnormalized result: I.fffff..fff g s (g is guard bit, s are sticky bits)

0.11111..111 1 1xx intermediate result which the tiny-check normalizes first 1.11111..111 1 xxx normalized result 10.00000..000 tiny-round rounds up if (since normalized g bit is one), so no underflow 1.00000..000 and result-rounded up to normal (g=1), no underflow

as opposed to

0.11111..111 1 0xx intermediate result which the tiny-check normalizes first 1.11111..111 0 xxx normalized result 1.11111..111 tiny rounding leaves it unchanged (normalized g bit now zero) so underflow (since denorm) and inexact (gs bits are nonzero) 1.00000..000 and result-rounded up to normal (g=1), but underflow is signalled

On Tue, Oct 29, 2024 at 2:29 AM anuani21 @.***> wrote:

@jjscheel https://github.com/jjscheel,

As per Allen and David discussion, I need to do some changes in the test in all FP extensions.Probably, I will raise a PR by next week.

— Reply to this email directly, view it on GitHub https://github.com/riscv-admin/dev-partners/issues/36#issuecomment-2443688181, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWBYHVRK4JWBWFZSXTZ55IO3AVCNFSM6AAAAAA5J4FNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBTGY4DQMJYGE . You are receiving this because you were mentioned.Message ID: @.***>

anuani21 commented 1 week ago

@jjscheel,

Need to do some changes for three operand instruction test cases in all FP extensions.I will raise a PR soon.

riscv-admin / dev-partners

FP Denorm ACT #36

Technical Group

ratification-pkg

Technical Liaison

Task Category

Task Sub Category

Ratification Target

Statement of Work (SOW)

Waiver

Pull Request Details

So, given a tiny-check with a "tiny-rounding" stage which normalizes (shift denorms so mantissa MSB=1) before the rounding, followed "result-rounding" stage which rounds the unnormalized result: I.fffff..fff g s (g is guard bit, s are sticky bits)

as opposed to