[PATCH] D101980: [RFC] [Coroutines] Put the contents of byval argument to the frame

John McCall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 12 00:42:35 PDT 2021


rjmccall added a comment.

In D101980#2752963 <https://reviews.llvm.org/D101980#2752963>, @ChuanqiXu wrote:

> In D101980#2752775 <https://reviews.llvm.org/D101980#2752775>, @rjmccall wrote:
>
>> That are semantically passed by value but "physically" passed as a pointer to a temporary? Yes, absolutely, depending on the target. Example: https://godbolt.org/z/oK1Yadjvq
>>
>> (I assume you meant "fine".) That's true, no. It is *uncommon* for a type to have a copy/move operation that isn't semantically equivalent to memcpy without also having a non-trivial destructor, but it's absolutely possible, both formally and in practice. Practical examples include relative pointers or structs containing a field signed with address-diversified pointer authentication.

(I meant to type "That's *not* true", but I think you got the point.)

> Many thanks to the sharing! Really appreciate it.

No problem.

>> Well, inalloca is a problem, because we actually only ever use inalloca when there's an argument type with a non-trivial copy/move/destroy operation. If you'd like to land a short-term fix just for byref, I think that might be okay while we figure out on llvm-dev what to do in general.
>
> Does it mean `byval` there? I would like to land a short-term fix for `byval` since the other approaches would take a long time.

Okay.  I can review this patch in the meantime.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101980/new/

https://reviews.llvm.org/D101980



More information about the llvm-commits mailing list