在 2020/1/21 下午4:07, Iain Sandoe 写道:
JunMa <ju...@linux.alibaba.com> wrote:
在 2020/1/21 上午9:34, JunMa 写道:
在 2020/1/21 上午12:39, Iain Sandoe 写道:
JunMa <ju...@linux.alibaba.com> wrote:
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa <ju...@linux.alibaba.com> wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa <ju...@linux.alibaba.com> wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa <ju...@linux.alibaba.com> wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is
created
for each coroutine parameter. While in current
implementation, we
only collect used parameters. This may lost behavior inside
constructor
and destructor of unused parameters.
This patch change the implementation to collect all parameter.
thanks for the patch.
I am not convinced this is the right way to fix this, we do
not want to increase
the size of the coroutine frame unnecessarily. I would like
to check the lifetime
requirements; such copies might only need to be made local to
the ramp function.
Iain
For type with trivial destructor, There is no need to copy
parameter if it is
never referenced after a reachable suspend
point(return-to-caller/resume) in the
coroutine. Since we are in front end, that should be
inital_suspend point. so we
can create field for type with non-trivial destructor first,
and skip unused parameters
in register_param_uses. I'll update the patch
I think that, even if the DTOR is non-trivial, the copy only
needs to be in the stack
frame of the ramp, not in the coroutine frame.
I do think this. It's just need more work on front end.
I think we already did the work, and know the answer (about param
uses in the body), right?
Yes, we may need extra work on copy parameters, I'll do this.
Having discussed this with Nathan (and I’ve also mailed Gor for
clarification). I think it might be
a good idea to wait for those responses before revising (it could
be that your original reading of
the wording is correct, and the clang impl. needs to be updated).
ok, thanks.
The reason why i consider about non-trivial destructors is that if
the destructors are called in ramp
function, actor function may has different status on something. the
testcase I attachted is such
example: it changes global variable in destructor.
Yes we all agree on this :-)
The issue is:
1. should the copy exist for the duration of the ramp only? (i.e.
copied to the ramp() stack frame)
2. should the copy exist for the duration of the resume() function?
(i.e. copied to the coro frame)
At the present, clang appears to do 1. when optimisation is on and 2.
without optimisation.
Nathan pointed out that the lifetime of an object should not depend on
the optimisation level.
Although I prefer 2, it seems that maybe clang is hard to control
this(not sure:), maybe new attribute).
So - I think we need some clarification on the intent (from the
designer) and maybe some revision
of the standard wording to make the lifetime clear.
Yeah, let's make this more clear. Thanks.
Regards
JunMa
thanks
Iain
