paulwalker-arm added a comment. In D124998#3494127 <https://reviews.llvm.org/D124998#3494127>, @aaron.ballman wrote:
> In D124998#3493791 <https://reviews.llvm.org/D124998#3493791>, > @paulwalker-arm wrote: > >> Just wanted to say this is not a new calling convention as such, but rather >> an existing one that is generally auto-detected based on function signature. >> The problem we're trying to solve here is that we need a way to allow a >> user to force the calling convention when the function signature would not >> normally choose it. > > Thanks for this information! It's still not clear to me whether there's > sufficient need for this extension. From this description, it sounds like > this will be rarely used because it's only necessary in one-off situations. > If that's correct, can those users make use of inline assembly instead of a > devoted named calling convention? It's hard to say how often this will be used but when used it will be fundamental to performance. I don't see inline assembly as a workable solution. It presents an unreasonable burden on a framework's user and will impact compiler optimisations. The ACLE exists to stop developers from needing to use inline assembly. You have to forgive my naivety here but some the calling conventions are target specific. Is it possible for them to safely alias for the parts of the code where memory is constrained? Or to put it another way, do the X86 and AArch64 calling conventions need to be uniquely identifiable? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124998/new/ https://reviews.llvm.org/D124998 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
