wangpc-pp 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...
Thanks for replying. I may not think it clearly. There are many ways to do the same thing. I think this PR wouldn't be the last time that someone try to add these builtins: * https://reviews.llvm.org/D71778 * https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/8 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
