spavloff wrote: > This sounds like a rejection of safe-by-default.
What do you mean by "safe-by-default"? Implementation must be correct, and produce the code that executes in accordance to standards and documentation. Any deviation from them is an error and should be fixed. Does it mean that such implementation would be "safe"? > 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. Users have different needs and can tune compilation using appropriate options. Those who need strict exception behavior chose suitable option set and should get code that behave as expected but probably has lower performance. And there is a large number of users who need maximum performance but can sacrifice exception strictness. They should use another set of options. Does using different compilation options solves this problem? > 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. There is no hope to produce code as performant as in default mode, but with strict exception semantics. So the only way to make a compiler suitable for all users is to provide means to tune it. > 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. There is no intention to remove constrained intrinsics (like `experimental.constrained.fadd`), because operand bundles could only be attached to function calls. The constrained intrinsics however need to change their shape in future to use operand bundles as well. > 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 new representation does not differ in this aspect from the existing one. FP operations are represented by function calls, they have side effect and proper ordering must be provided by the existing LLVM mechanisms, a developer does not need to know about these properties. There is a hope that using side effect more fine-grained than "inaccessiblememonly" could make FP code faster for non-default modes, but it is in future. > 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. If IRBuilder does not set strictfp when it should, it usually ends up with assertion violation or verification errors. I guess in this case IR is created by some tool, probably MLIR-based, not by clang? Maybe this is a use case that we do not support enough well now and it would be helpful to investigate it. 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
