kpneal wrote: > It does not look as a good base for safety. Many users want the code in > non-default FP modes to be more efficient, Now any any deviation from the > default mode requires use of constrained intrinsics in the entire function, > but now such solution exhibits poor performance, unsuitable for practical > needs. Eventually optimizations will involve the constrained intrinsics too.
This sounds like a rejection of safe-by-default. Keep in mind that "unsuitable for practical needs" doesn't mean that everyone agrees with you about what level of performance is unsuitable for one's practical needs. And a compiler that generates good performing code with random FP exceptions inserted is, in my experience, unusable if one runs with traps on. Trading performance for exception safety is a valid choice for some. Trading away all of the performance lost because few optimization passes know how to deal with the constrained intrinsics is still a valid choice for some. WRT eliminating the constrained intrinsics completely, I thought that operand bundles could only be attached to function calls and not regular instructions? If I'm wrong, we _still_ have a problem because there are so many uses of the regular FP instructions that we can't be safe-by-default and still use those instructions. We'd need to keep some kind of the constrained intrinsics (or new intrinsics) that give us replacements for the regular FP instructions. I do like the idea of finding ways to get the behavior we need without having to have most developers care about strictfp. Reality is that most LLVM developers don't have any interest in strictfp. If we're piggybacking off of other parts of the LLVM design that are already widely supported then that makes our jobs much easier. If we can rely on marking calls as "inaccessiblememonly" or other side effects then that sounds quite helpful. The problem I've run into with the IR Verifier is that the strictfp mode of the IR Builder needs to be turned on in all cases needed, but currently doesn't because the IR Builder's constructor doesn't know to construct itself in strictfp mode. Now, many instantiations of the IR Builder occur with the constructor able to chase down the function definition and find out if strictfp mode is required. Many, hundreds, don't have that luxury and thus each has to be touched and corrected. Having the IR Builder keep this strictfp mode and automatically add side-effect notes and/or operand bundles when required allows most developers to continue to not care about strictfp but preserve strictfp functionality at the same time. We'd still need a way to find out that some cases were missed because, for example, a strictfp attribute was forgotten. So the IR Builder instantiations still need to be corrected, but that's work in progress. Eventually the IR Builder could be changed to add bundles to, I don't know, all function calls that have a FP type passed to them perhaps? No IR Builder changes are needed for this patch, of course, but I do want us to make sure we're keeping the whole design in mind as we go. https://github.com/llvm/llvm-project/pull/109798 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
