[PATCH] D79744: clang: Add address space to indirect abi info and use it for kernels
Matt Arsenault via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 2 15:23:35 PDT 2020
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
More information about the cfe-commits
mailing list