arsenm added a comment. In D79744#2069620 <https://reviews.llvm.org/D79744#2069620>, @rjmccall wrote:
> In D79744#2069324 <https://reviews.llvm.org/D79744#2069324>, @arsenm wrote: > > > In D79744#2050498 <https://reviews.llvm.org/D79744#2050498>, @rjmccall > > wrote: > > > > > > For the purpose here, only the callee exists. This is essentially a > > > > freestanding function, the entry point to the program. > > > > > > I'm definitely not going to let you add a new "generic" argument-passing > > > convention and then only implement exactly the parts you need; that's > > > just adding technical debt. > > > > > > I'm not sure what you mean here. I don't really want or need a totally new > > generic argument passing convention. Not every IR feature is expected to be > > implemented by every backend. For instance, inalloca/preallocated exist > > solely to implement the x86 windows ABI and no other target tries to handle > > them. This is just another flavor of the same fundamental concept of a > > parameter attribute needed for a target specific calling convention. > > > I mean the Clang code for supporting this new convention, not the IR support. > Of course LLVM has target-specific attributes. I think this is converging to adding a new IR attribute that essentially just provides the pointee type for ABI purposes. I guess my name ideas for this would be "indirect", "value", "memoryvalue", "abitype"? I forget that frontends exist sometimes, so I'm not sure I understand your clang side objection. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79744/new/ https://reviews.llvm.org/D79744 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
