codegenv2: improve multi argument generation #395
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JakeHillion
force-pushed
the
no-root-type
branch
3 times, most recently
from
d84b626 to
df5fd58
Compare
tyroguru
approved these changes
Oct 30, 2023
JakeHillion
force-pushed
the
no-root-type
branch
from
df5fd58 to
db65d7e
Compare
Codecov Report
@@ Coverage Diff @@
## main #395 +/- ##
==========================================
+ Coverage 68.80% 68.86% +0.05%
==========================================
Files 116 116
Lines 11420 11458 +38
Branches 1899 1903 +4
==========================================
+ Hits 7857 7890 +33
- Misses 2587 2590 +3
- Partials 976 978 +2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
@JakeHillion has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
1 similar comment
|
@JakeHillion has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
JakeHillion
added a commit
to JakeHillion/object-introspection
that referenced
this pull request
Oct 31, 2023
Summary: Adds a new function `CodeGen::codegenFromDrgns` which runs multiple drgn root types through one `DrgnParser`. Stores the naming for the output within this function as we previously decided that when doing the actual codegen, which is too late with multiple root types. This new function is used in `OIGenerator` when you have multiple OIL calls within one input object. Rather than producing separate `.o`s with likely duplicate code for each callsite, we produce a single `.o` that contains both calls. For calls with types with significant overlap this should be a significant reduction in work. The downside is the calls can't have different features, but this could be solved in the future by namespacing the code based on features/config within the generated `.cpp` - the pros seem to outweigh the con. This should also be used with `oid` in multi probe mode as it would again significantly reduce the work it has to do. I didn't do this yet as it requires changing the cache. As I've got a big refactor cache ongoing at the minute it makes sense to wait until after that's landed to make this change. Test Plan: Generally tested with GitHub CI. Tested the new multi call OILGen with the new example seen below. Outputs the following code with two root calls: P869569859 - note that `VectorOfStrings_0` is the only instance, whereas previously we'd have generated it in two files. Differential Revision: D50835153 Pulled By: JakeHillion
JakeHillion
force-pushed
the
no-root-type
branch
from
db65d7e to
87be5a6
Compare
|
This pull request was exported from Phabricator. Differential Revision: D50835153 |
Summary: Adds a new function `CodeGen::codegenFromDrgns` which runs multiple drgn root types through one `DrgnParser`. Stores the naming for the output within this function as we previously decided that when doing the actual codegen, which is too late with multiple root types. This new function is used in `OIGenerator` when you have multiple OIL calls within one input object. Rather than producing separate `.o`s with likely duplicate code for each callsite, we produce a single `.o` that contains both calls. For calls with types with significant overlap this should be a significant reduction in work. The downside is the calls can't have different features, but this could be solved in the future by namespacing the code based on features/config within the generated `.cpp` - the pros seem to outweigh the con. This should also be used with `oid` in multi probe mode as it would again significantly reduce the work it has to do. I didn't do this yet as it requires changing the cache. As I've got a big refactor cache ongoing at the minute it makes sense to wait until after that's landed to make this change. Test Plan: Generally tested with GitHub CI. Tested the new multi call OILGen with the new example seen below. Outputs the following code with two root calls: P869569859 - note that `VectorOfStrings_0` is the only instance, whereas previously we'd have generated it in two files. Differential Revision: D50835153 Pulled By: JakeHillion
JakeHillion
force-pushed
the
no-root-type
branch
from
87be5a6 to
a49f0e7
Compare
|
This pull request was exported from Phabricator. Differential Revision: D50835153 |
|
The rebase on this is horrific - putting it on hold for now. Might wait until #421 lands as this was mostly for OILGen anyway then redo it. |
|
Going to drop this for now. The rebase was bad enough that I'll rewrite it at some point. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Adds a new function
CodeGen::codegenFromDrgnswhich runs multiple drgn root types through oneDrgnParser. Stores the naming for the output within this function as we previously decided that when doing the actual codegen, which is too late with multiple root types.This new function is used in
OIGeneratorwhen you have multiple OIL calls within one input object. Rather than producing separate.os with likely duplicate code for each callsite, we produce a single.othat contains both calls. For calls with types with significant overlap this should be a significant reduction in work. The downside is the calls can't have different features, but this could be solved in the future by namespacing the code based on features/config within the generated.cpp- the pros seem to outweigh the con.This should also be used with
oidin multi probe mode as it would again significantly reduce the work it has to do. I didn't do this yet as it requires changing the cache. As I've got a big cache refactor ongoing at the minute it makes sense to wait until after that's landed to make this change.Test plan