I’ve been trying for a couple of months to organize regular sync up meetings of a working group to discuss floating-point issues. Unfortunately, I’ve been failing miserably on the “organize” part of this. Most recently, I changed the link for the meet up but left the old link in the meeting minutes and agenda document. I apologize to anyone who tried to attend but was unable to find us.
I’m trying again this month. The meeting is scheduled for February 21 at 6 PM UTC (10 AM Pacific, 1 PM Eastern). The link for the meeting is https://meet.google.com/kxo-bayk-nnd
My intention for this meeting is to provide a regular time for live discussion to help us converge on consensus for disputed issues and to give people a forum to request help getting their patches reviewed. Please send me any topics you’d like to discuss.
At the upcoming meeting, I would like to discuss the semantics of fast-math flags with special attention given to nnan, ninf and denormal-fp-math.
This meeting is of course open to all members of the LLVM community, but I’d like to specifically invite the following people who have been involved in recent discussions or who I know are working on floating-point changes.
No slight is intended to anyone I have not mentioned. I’m sure I’m missing some obvious contributors.
I realize that no time will be convenient for everyone. If you are interested in participating but can’t make it at the time I have currently scheduled, please let me know what I can do to include you.
Although I am not an FP expert (or even especially knowledgable), I do a lot of bulk testing of LLVM transformations and I sometimes run afoul of these transformations:
I wonder if the FP working group might be willing to take a look at this and try to decide whether these are something that we should prioritize fixing or, alternatively, change the definition of what is an acceptable FP transformation to include these?
Thanks!
Yes! This is exactly the kind of thing I hope this working group will talk about.
In general, I’m not sure Alive handles fast-math transformations well. This is at least in part because the semantics of the fast-math flags are not well defined. That’s something we’re working on, but it’s tricky because these flags are specifically intended to allow the compiler to disregard normal semantics. It’s something we want to address though.
I updated the Compiler Explorer repro for the first case to this: https://llvm.godbolt.org/z/d4qc83q7P It took me a while to understand what Alive thought was wrong with this transformation. If I’ve understood correctly, the thing that Alive doesn’t like it the transferring of the nsz flag to the select instruction. Without that, Alive is happy. https://alive2.llvm.org/ce/z/YDVM26
This seems to be based on the assumption that nsz on the select instruction allows the instruction to change the sign of the returned value if the value that would be returned is a zero. This is debatable, I think, but I can’t see any reason InstCombine should be setting the nsz flag on the select instruction in that case.
But I guess you’re also asking about the relative priority of issues like this, right? Right now, mixing fast-math flags from one instruction to the next like that example is probably not something that happens in real world uses. However, being able to turn fast-math on and off at a fine granularity is something I see as very useful as a part of broadly enabling fast-math but then turning it off locally where it is causing problems. So, I’d like to fix these kinds of things. That’s just my opinion, which is why I think we need a group to sort all this out and arrive at agreed upon answers.