You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we outline all indirect calls. There are two reasons for this:
We don't know if the call target is mappable or not
If it is mappable, we don't know if it was annotated with "yk_outline" (which forbids inlining)
At least in the hardware tracer 1) is easy to work around this by peeking ahead at the next block in the trace. If the block is mappable, the call can be inlined. Unfortunately, this doesn't currently work for the software tracer, since it doesn't report unmappable blocks (however this is a separate issue).
A solution for 2) would be to not serialise AOT IR for functions annotated with "yk_outline". This means that any function we have IR for are guaranteed to be inline safe and the trick from 1) works again.
The text was updated successfully, but these errors were encountered:
At the moment we outline all indirect calls. There are two reasons for this:
At least in the hardware tracer 1) is easy to work around this by peeking ahead at the next block in the trace. If the block is mappable, the call can be inlined. Unfortunately, this doesn't currently work for the software tracer, since it doesn't report unmappable blocks (however this is a separate issue).
A solution for 2) would be to not serialise AOT IR for functions annotated with "yk_outline". This means that any function we have IR for are guaranteed to be inline safe and the trick from 1) works again.
The text was updated successfully, but these errors were encountered: