[llvm-dev] FW: clarification needed for the constrained fp implementation. (original) (raw)
陳韋任 via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 7 07:45:04 PST 2017
- Previous message: [llvm-dev] FW: clarification needed for the constrained fp implementation.
- Next message: [llvm-dev] FW: clarification needed for the constrained fp implementation.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I was actually thinking that fegetround and fesetround would always be translated into llvm.get.roundingmode and llvm.set.roundingmode at least initially, because it’s a bit of trouble to prove that they are being used to implement the local rounding mode idiom. Certainly recognizing that kind of usage is more work than a front end should be doing.
I would propose the begin/end local rounding mode intrinsics as a convenience for cases where some user (probably never clang) specifically knew that this was the intended behavior. I believe Wei has a use case like that, and I’ve also spoken to someone working on the Julia language who would like to be able to do this.
Okay.
That does still leave the problem of what happens if there is a function call inside a pair of begin/end local rounding mode intrinsics. I’m not entirely sure the best way to handle this. Do we try to restrict calls that might change the rounding mode or do we leave it up to the front end and/or user to make sure things are safe.
From the 2011 discussion thread on Intel Forum [1], seems the pragma only affects the function containing it. That sounds reasonable to me.
[1] https://software.intel.com/en-us/forums/intel-c-compiler/topic/284430
As for the C/FENVACCESS case, I seriously feel like the way that pragma is defined leaves users with a huge amount of room to shoot themselves in the foot. If I’m reading the specifications correctly, it says that changing from a scope with FENVACCESS on to a scope with FENVACCESS off or vice versa without the FP environment in its default state is undefined behavior. At some point it would probably be nice to have a sanitizer that checks this.
I think you can just implement the pragma without worrying too much about how user might mis-use them. Leave the front-end or sanitizer to take care of those issues.
-- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171107/e49b3f54/attachment.html>
- Previous message: [llvm-dev] FW: clarification needed for the constrained fp implementation.
- Next message: [llvm-dev] FW: clarification needed for the constrained fp implementation.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]