[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. That's a fair point. I agree that separate allocas would make this a lot cleaner, in both IR and frontend implementation. We could also set an inalloca bit (+ field index? or maybe keep the arg index -> field index mapping on the CGFunctionInfo) on each arg info *in

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment. In https://reviews.llvm.org/D43842#1022546, @rjmccall wrote: > Okay. In that case, this seems correct, although it seems to me that perhaps > `inalloca` is not actually orthogonal to anything else. In fact, it seems to > me that maybe `inalloca` ought to just be a bit on

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd closed this revision. compnerd added a comment. SVN r326362 Repository: rC Clang https://reviews.llvm.org/D43842 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Alright, yeah, we can fix that later. LGTM. Repository: rC Clang https://reviews.llvm.org/D43842 ___ cfe-commits mailing list cfe-commits

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added a comment. Yeah, this is still an indirect return. I can see your point about the representation, nfortunately, I think that change is way out of scope for this. That would be a pretty large and invasive change to wire that through. Repository: rC Clang https://reviews.llvm

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. Okay. In that case, this seems correct, although it seems to me that perhaps `inalloca` is not actually orthogonal to anything else. In fact, it seems to me that maybe `inalloca` ought to just be a bit on the CGFunctionInfo and the individual ABIInfos should be left

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment. In https://reviews.llvm.org/D43842#1022498, @rjmccall wrote: > Ugh, I hate `inalloca` *so much*. > > It's still an indirect return, right? It's just that the return-slot pointer > has to get stored to the `inalloca` allocation like any other argument? Correct. Repos

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-28 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. Ugh, I hate `inalloca` *so much*. It's still an indirect return, right? It's just that the return-slot pointer has to get stored to the `inalloca` allocation like any other argument? Repository: rC Clang https://reviews.llvm.org/D43842 _

[PATCH] D43842: CodeGenObjCXX: handle inalloca appropriately for msgSend variant

2018-02-27 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd created this revision. compnerd added reviewers: rjmccall, rnk. objc_msgSend_stret takes a hidden parameter for the returned structure's address for the construction. When the function signature is rewritten for the inalloca passing, the return type is no longer marked as indirect but ra