Nathan Sidwell <nat...@acm.org> wrote:
On 7/16/20 11:56 AM, Iain Sandoe wrote:
It's unfortunate the original plan of handling lifetime issues in a
gimple pass didn't work out.
I’ve revisited this (on balance every couple of months, I suppose when it
gets tricky doing
something in the FE). However, it seems to me that the complexity is
inherent and all we
would do is to punt that from the FE into the ME.
for example, on the limited tests I made with coro suspend point lowering
delayed until post
LTO, I ran into issues with loads of pointers to the promise getting
hoisted out of loops with
suspend points. Of course, everything is probably fixable - and there’s an
existing impl that
defers the frame consruction to the ME (noting that there's a comment from
the authors there
saying that they do end up with some unnecessary frame entries).
some things are easier to analyze in tree-land and some things are def.
easier when the
code has been flattened.
There’s at least one optimisation of the size of the coroutine frame that I
think would be
much more difficult (maybe impossible, depending on what information has
been discarded)
later in the pipeline.
so .. my current estimate remains that it would be “six of one, half a
dozen of the other”.
+struct interesting
+{
not a very good name. As it's not in an anonumous namespace, it has
external linkage, and hence ripe for ODR breakage, if some other TU is
interested about something else :) Is there a more specific name it
could have?
changed to ‘coro_interesting_subtree’.
+ else if ((tmp_target_expr_p (expr)
+ && !p->temps_used->contains (expr)))
too many parens here.
thanks, fixed
pushed to master.
Iain
* for master (at least on Darwin):
we now get 100% pass on cppcoro
and 99% on folly (one expected fail, one to be analyzed).
