multiple module tests
Details
Diff Detail
Event Timeline
Looks great, only minor comments to make stuff more readable.
Since you're ahead of me (I'm still working on finishing up the testcases for the last 7 cases) do you want to look at adding some global variable tests as well?
unittests/ExecutionEngine/MCJIT/MCJITMultipleModuleTest.cpp | ||
---|---|---|
36 | This test should probably stay in MCJITTest.cpp | |
62 | test1 is not very descriptive..maybe name the tests something else like independent_modules to express that modules don't have any dependencies on each other.. | |
65 | Using the variable M is convenient when there's only one module, but for multiple modules it's hard to follow what's going on. Maybe declare each module separately to make it clear that FA refers to a function in module A: OwningPtr<Module> A; | |
70 | <caller module> is not a good name here.. Andy's naming scheme was clearer to understand, so maybe just "B" for the module that contains function FB is better? | |
123 | Maybe a short comment here that explains what the test verifies would be good. For the tests I'm writing, I just pasted the comments Andy provided. For example, something like: Populates Modules A, B and C: |
Yeah, I will take a look at the global variable tests and cross module linking case as well..
Looks Great! Only minor notes:
- indenting looks a bit off. I recommend just running clang-format on the whole file.
- regarding the finalize() call, let's meet up today with Andy to see if we can agree on an interface.
- let's merge this into Andy's MCJIT branch (mcjit-multi-modules) so we are all on the same branch.
unittests/ExecutionEngine/MCJIT/MCJITMultipleModuleTest.cpp | ||
---|---|---|
10 | This description also needs updating. | |
25 | Are we still using this M? If not, I think we can skip the SetUp routine. |
This description also needs updating.