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 addition* to the standard ABI info; then most of the cases could just do a final store after their normal transformations. Are there really no cases where you have to e.g. sign-extend before doing inalloca, or do you just special-case all that in actual argument emission?
Yeah, the block-soup basis of LLVM IR is really annoying for a lot of things that otherwise ought to be simple tasks. I spent some time trying to think about how I could support (scoped) dynamic allocas in coroutines for Swift and eventually just gave up and introduced a bunch of intrinsics based around a token. Trying to optimize static allocas based on lifetime intrinsics isn't going to be a picnic, either. 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
