Displaying 4 results from an estimated 4 matches for "coro_".
Did you mean:
coro
2017 Oct 18
2
Is every intrinsic norecurse?
> From: piotrekpad at gmail.com [mailto:piotrekpad at gmail.com] On Behalf Of Piotr Padlewski
> Sent: den 16 oktober 2017 17:33
>
> Hi David,
> The patch didn't get a lot of attention, so probably others does not
> consider it a huge deal. Anyway, if someone is willing to review this, I
> can pursue rebasing it.
Okay. We are interested in getting something akin to your
2017 Jan 03
2
RFC: Allow readnone and readonly functions to throw exceptions
...This should be mostly mechanical, I hope, but it's a decent amount
> of churn.
The behavior around intrinsics today is that they're implicitly marked
NoUnwind unless they're specifically annotated as [Throws], of which
there are very few instances (statepoints, stackmap, patchpoint,
coro_*). My intent was to (document and) keep this behavior.
-- Sanjoy
2017 Oct 20
2
Is every intrinsic norecurse?
...list is not complete - pretty much every intrinsic that can throw
> can also recurse (not for any fundamental reason -- just that
> intrinsics that throw do that by calling some other function, and that
> callee function can also be recursive). You may also want to ask Gor
> about the coro_ intrinsics.
>
> The way you're going about the change is risky though -- have you
> considered adding a NoRecurse property instead? That way you can
> start marking most of the "obviously" non-recursive intrinsics right
> away and slowly expand the set.
>
> Thi...
2017 Jan 03
4
RFC: Allow readnone and readonly functions to throw exceptions
LLVM today does not clearly specify if a function specified to not
write to memory (i.e. readonly or readnone) is allowed to throw
exceptions.
LangRef is ambiguous on this issue. The normative statement is
"[readnone/readonly functions] cannot unwind exceptions by calling the
C++ exception throwing methods" which does not decide an answer for
non C++ languages. It used to say (h/t