[MooreToCore][Sim] Added support for moore.fmt.real

[KavyaChopra04]

Since LLVM doesn't have a very clean separation between printing out floats in FP vs Scientific Notation (see toStringImpl here), I decided to do what Verilator does here : call snprintf. So for now, we're doing C-style prints - I plan to make a patch to LLVM to disambiguate toStringImpl for FP notation, but that's for later.

Overview:

1. By default, the precision for floating point numbers is 6 for %f and %e
2. $fieldWidth is used to determine padding, and $fracDigits is used to denote the number of digits after the decimal point/the alphabet 'e' - the actual formatting is handled by snprintf under the hood
3. %g has a unique formatting logic:

For exp ≥ 0:
Uses decimal notation if exp + 1 ≤ max(1, fracDigits), otherwise switches to scientific notation with max(0, fracDigits - 1) fractional digits

For exp < 0:
If exp ≥ -4: Uses decimal notation with max(b - 1, 0) + |exp| fractional digits
If exp < -4: Uses scientific notation with max(b - 1, 0) fractional digits
Everything is stripped of trailing zeroes after the decimal point/the alphabet 'e'

which, as expected, is in conjunction with this

I've introduced this patch to fix the current fmt.real legalization errors and improve test coverage. I think it is beneficial to merge this even if we remove the formatting folders later, since this might serve as reference code for the arcilator runtime (Relevant Issue)

Error diff (against current main):

-67 error: failed to legalize operation 'moore.fmt.real'
+15 error: failed to legalize operation 'moore.fneg'
 +2 error: 'llhd.wait' op operand #0 must be variadic of a known primitive element, but got 'f64'
 +2 error: integer bitwidth is limited to 16777215 bits
 +1 error: 'hw.param.value' op result #0 must be a known primitive element, but got 'f64'
 +1 error: 'llhd.wait' op expects parent op 'llhd.process'
-46 total change

[fzi-hielscher]

Thank you for working on the formatting ops 👍
I won't have time to properly look at this until next week, but as a high level thought: At this point, we should just get rid of the fold methods for the number formatting ops. They never provided much benefit to begin with. And the more options we add, the higher are the chances that there will be some formatting mismatch between the folder and whatever tool is running the simulation. This will then cause strange inconsistencies in the output.
Sorry if this has lead to some unnecessary effort on your side.

It is also not obvious what should be its own operation and what can be controlled by an attribute, see #7692. I think my current preference (at least for the sim dialect) would be to only put "hard" requirements, like the radix for integers, into the operations and move "soft" specifications, for which we just expect best-effort implementations, into something like a shared NumberFormattingHintsAttribute.

[KavyaChopra04]

@darthscsi @seldridge, sorry to add you as reviewers - something had gone wrong with a prior rebase

[KavyaChopra04]

Thank you for working on the formatting ops 👍 I won't have time to properly look at this until next week, but as a high level thought: At this point, we should just get rid of the fold methods for the number formatting ops. They never provided much benefit to begin with. And the more options we add, the higher are the chances that there will be some formatting mismatch between the folder and whatever tool is running the simulation. This will then cause strange inconsistencies in the output. Sorry if this has lead to some unnecessary effort on your side.

It is also not obvious what should be its own operation and what can be controlled by an attribute, see #7692. I think my current preference (at least for the sim dialect) would be to only put "hard" requirements, like the radix for integers, into the operations and move "soft" specifications, for which we just expect best-effort implementations, into something like a shared NumberFormattingHintsAttribute.

Ah, I see - I think that the patch (both int and real formatting) might be helpful and serve as reference code for future library implementations (as discussed with @fabianschuiki), so it might be helpful to keep it in. What do you think?

[KavyaChopra04]

@fabianschuiki, could you please take a final look and merge?

[fabianschuiki]

LGTM! Thanks a lot for plumbing this all the way through to the Sim dialect, adding thorough tests, and including a constant folding implementation as a reference. Very cool stuff! Glad to see that you're getting rid of 46 errors in sv-tests 😏 💯 🥳