jrtc27 wrote: > > I support adding these builtins personally, but I think we need more > > discussions on the design. We can achieve the same thing via inline > > assemblies, that's true. But, from the compiler side, inline assemblies are > > kind of barriers, we can't do a lot of optimizations/reorderings if inline > > assemblies exist. If we make it a builtin, these limitations can be loosed > > I think. > > Inline assembly is only a barrier to moving load/stores and other side > effecting instructions. And only if the inline assembly is marked volatile or > has "memory" clobber. It should not affect moving arithmetic. I think these > CSR intrinsics would also need to be barriers against load/stores and other > side effects to be the most conservative to access any CSR.
Yes, exactly; you have no clue what the semantics of the CSR are (if you did, you'd have a named intrinsic, like `__builtin_readcyclecounter()`) because it is just an arbitrary number. Also, in what world do you need compiler optimisations around general CSR accesses? That's normally relatively cold performance-non-critical code... https://github.com/llvm/llvm-project/pull/85091 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
