feat(hugr-llvm): Emit rounding operation for FloatOps::fround extension ops#2949
feat(hugr-llvm): Emit rounding operation for FloatOps::fround extension ops#2949maximilianruesch wants to merge 3 commits intomainfrom
FloatOps::fround extension ops#2949Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2949 +/- ##
==========================================
- Coverage 83.84% 83.83% -0.01%
==========================================
Files 267 267
Lines 52923 52933 +10
Branches 46854 46864 +10
==========================================
+ Hits 44371 44379 +8
Misses 6283 6283
- Partials 2269 2271 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
acl-cqc
left a comment
There was a problem hiding this comment.
Generally this looks fine, but I'm trying to understand the connection to Quantinuum/guppylang#1561. This PR implies that the current situation is that we can't compile rounding at all, even without an extra precision argument?
| #[case::fmul(FloatOps::fmul)] | ||
| #[case::fdiv(FloatOps::fdiv)] | ||
| #[case::fpow(FloatOps::fpow)] | ||
| #[case::fround(FloatOps::fround)] |
There was a problem hiding this comment.
The thing that worries me here is that fround appears to be unary, whereas all the others seem to be binary (taking two floats)....
There was a problem hiding this comment.
This is not true, fneg is also unary and appears in the test cases.
Adds
FloatOps::froundLLVM lowering support. This is to add support for rounding operations in Selene, connected to Quantinuum/guppylang#1561.I am a bit unsure how the tests work, but simply adding another test case in line with the existing ones seems to work fine.