andrew.w.kaylor added a comment. In D62731#1784225 <https://reviews.llvm.org/D62731#1784225>, @rjmccall wrote:
> ... The big problem is that intrinsic calls are not arbitrary code: the vast > majority of intrinsics (e.g. all the ARM vector intrinsics, many of which can > be floating-point) are marked `IntrNoMem` (which I believe corresponds to > `readnone`), which means calls to those intrinsics can be reordered with > other code whether or not that code has arbitrary side-effects. Oh, you're right. With the constrained intrinsics we are currently handling that by using IntrInaccessibleMemOnly as a proxy for access to the FP environment, but that's stronger than we'd want for architecture-specific intrinsics in the default case. We have talked about an fpenv-specific attribute, but nothing has been done. So, I guess that does leave us in the situation where rounding controls might not be correctly respected if target-specific intrinsics are used. > It's good that people are looking at achieving better modeling for the x86 > backend, but we need to have a plan that doesn't require heroic effort just > to get basic correctness. Do you mean in the backend? If so, I don't think that's possible. The backends just don't have any sort of feature that could be used to get conservatively correct behavior for cheap the way intrinsics give it to us in the middle end. Once you go into instruction selection things get very low level in a hurry. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62731/new/ https://reviews.llvm.org/D62731 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
