Avoid copying out/inout args when inlining functions #4877
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposal/work in progress for a way of reducing the number of copies introduced when inlining.
On particularly problematic case is when you have a big struct (eg, all the headers) that is passed around to functions as an
inout
argument so they can access/modify it. Introducing a copy of all the headers is particularly inefficient, and tough to later optimize away if it was unnecessary.This change just has a minimal check -- if the actual argument passed to an
inout
orout
argument is local to the caller, it can't possibly be accessed by the callee directly, so no copy is needed -- the inlined code can just access it directly.A more general check would be to actually look at the callee -- if it does not access whatever is passed as an argument directly or indirectly, then no copy is needed. The indirectly part is complex -- requires looking recursively at whatever the callee calls, including any extern functions or methods on instances.
Or perhaps there should be a target-specific policy that controls this -- would allow better target-specific understanding of externs and what they do.
The problem is connected to doing too much in the frontend -- function inlining happens in the frontend (when arguably it should not), in order to allow inlining into type params (
bit<N>
andint<N>
in particular). If we remove the general inlining in the frontend (and only do it in the midend), it would greatly help with target-specific policies and tweaks.