spavloff wrote: I don't think this feature can be implemented in a single patch. There are many problems that must be solved prior to introducing FP bundles.
As I understand, your patch is based on #135658. The latter may appear abandoned, but it is not, the focus has simply shifted to #188297 and its follow-ups. That PR does not even introduce bundles, its goal is to implement support for optional side effects for floating-point intrinsics, which is a prerequisite for the bundle-based model. The blocking issue for the bundle-based model is now optimizations. If the same intrinsic is used for both default and strictfp modes, the intrinsic calls become subjects to optimizations. However, some transformations become invalid in the general case. For example, the transformation `sin(x)/cos(x) -> tan(x)` is not allowed if `sin` and `cos` are evaluated using different rounding modes. So, to use the non-constrained function in strictfp function we need to audit use of the FP intrinsics in instruction combiner and other optimization passes, and change the use appropriately. Without this step compiler can generate incorrect code. I see support for FP instructions in your patch. It is an important direction that, as far as I know, is not currently being developed by anyone. As I understand, the new functions, like `llvm.fadd` must first be developed as replacements for the corresponding instructions so that they can participate in the same transformations as the instructions. Maybe they could even deprecate the instructions. Then, once FP bundles become available, these intrinsics could represent the instructions in strictfp code. Having a parallel line of development could be a great thing. https://github.com/llvm/llvm-project/pull/191613 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
