efriedma added a comment. On a normal, stack-based machine, there are two ways to pass an aggregate to a function: directly, or indirectly. Directly means something like "byval" or "preallocated": the value of the pointer is not a value the caller can control, but instead refers to some fixed offset on the stack. Indirectly means that the caller actually passes a pointer to the function; essentially, the function actually takes a pointer as an argument, not an aggregate.
For byval/preallocated/inalloca, the callee "owns" the memory, loosely speaking. If that's not the case here, it's probably a bad idea to use the existing markings. > However, it is technically permitted for the callee to introduce a write to > the argument, although nothing does this in reality Realistically, there isn't much incentive for optimizations to introduce new writes to byval arguments, but they definitely could in the future. (It might make sense to optimize out a memcpy from a byval argument to an alloca in more cases.) > The optimizer never pieces this back together to see that this is really just > a copy from constant memory, so we end up stuck with expensive stack usage. If the code writes to the variable, or the address escapes, I think there's no getting around the expensive stack usage. If we can prove there are only reads, we can eliminate the alloca in more cases, I guess. ----- Overall, this approach seems reasonable. ================ Comment at: llvm/docs/LangRef.rst:1081 + ``inmem`` pointer, unless it is known this will not produce an + observable change in the caller. The pointer may have any address + space and may be read only. ---------------- Not sure "unless it is known this will not produce an observable change in the caller" is really useful. "It is not generally permissible to introduce a write" should be clear enough; the memory model implies that a "write" might actually correspond to multiple store instructions. ================ Comment at: llvm/docs/LangRef.rst:1089 + ``byval``. If the alignment is not specified, then the code generator + makes a target-specific assumption. + ---------------- As far as I can tell, this doesn't include any provision for the caller to actually allocate "inmem" memory. Maybe we should forbid calls with "inmem" arguments. (The function would have to be called by some code not written in LLVM IR.) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81311/new/ https://reviews.llvm.org/D81311 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
