-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix min_float32 for parsing float literals #4229
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I'm not sure about this PR.
Subnormal values lose precision. I think if we want to accept them as float32's, we should also check that they are exactly representable as float32?
I grant this is also a little weird because if your input is e.g. 1/3, that will be represented as a python f64, and it's not exactly-representable as a f32. But we'll still cast it to a Triton f32. So why have a special case for subnormals? Except I feel like it's one thing to lose half the mantissa bits of 1/3, while it's another thing to lose potentially all but one of the mantissa bits of a f64 that is represented as an f32 subnormal. |
I agree with Justin, in addition to that one thing to consider is that this breaks backward compatibility and may break existing kernels in a non trivial way. |
Hmmm, those are fair points. There should be a way to produce custom constexpr types somehow, though. e.g. what about something like this?
|
can you just assign the constexpr and do tl.cast to get to the type you want? |
I did what y'all suggested, and it seems to have been smart enough to do the right thing, turning it into an immediate.
Thanks both :) |
Pull request was closed
The minimum normal 2**-126, but the minimum denormal is 2**-23 times smaller than that.