This is a first step toward getting proper support for aggregate loads and stores.
Details
Diff Detail
Event Timeline
This needs to go to llvm-commits. I'll review once that's done. I don't see anything major on a quick scan, but I haven't given it a careful read yet either.
What do you expect me to do except posting this in llvm-commit ?
I think this is pretty safe to get that in. This is straightforward and does not do much, but would serve as a base to continue the work.
Nit picks inline. This is really close to ready for submission. The only change I'd really like to see is the change from BasicBlockPass to FunctionPass and the removal of dead member variables.
lib/Transforms/Scalar/AggregateMemAccessRemoval.cpp | ||
---|---|---|
11 ↗ | (On Diff #20372) | Grammar. Possibly: "This transforms removes load ans stores of aggregate type by replacing them with equivalent scalar loads and stores." Also, not that this doesn't handle *all* aggregate loads and stores (yet.) |
36 ↗ | (On Diff #20372) | Its more canonical to use a FunctionPass and a foreach loop using inst_range. |
38 ↗ | (On Diff #20372) | I don't think either of these are used in this version of the code? |
45 ↗ | (On Diff #20372) | What's this using line for? |
60 ↗ | (On Diff #20372) | If you use a function pass, this initialization function can just disappear. Along with the member variables. |
Make this a Function pass and address various comments. Removed many instance fields that where not necessary anymore.
My primary question is why this isn't just an instcombine, using insertvalue / extractvalue to reconnect the aggregates?
@chandlerc - Because we talked about that last time and it was rejected for some reason I don't really remember. I would strongly prefer we land this in something close to it's current form and then iterate in tree. This has topic has been stalled on census for months. Honestly, I sorta of agree with you, but let's revisit that separately.
@deadalnix - LGTM w/nits applied.
lib/Transforms/Scalar/AggregateMemAccessRemoval.cpp | ||
---|---|---|
91 ↗ | (On Diff #20723) | You might want to make sure the size of the element is the size of the struct, otherwise we're loosing dereferencability information here. |
95 ↗ | (On Diff #20723) | Add a TODO about preserving metadata please. |
102 ↗ | (On Diff #20723) | This should be handled via an outer worklist not recursion, but please fix this as a separate change. Actually, sorry, you're not testing this at all. *Delete* this line and then let's revisit in another change. |
118 ↗ | (On Diff #20723) | Add a test for this case please. |
lib/Transforms/Scalar/AggregateMemAccessRemoval.cpp | ||
---|---|---|
91 ↗ | (On Diff #20723) | Is that possible that they differ for a one element struct ? I can add this as an assert because I don't think this possible at all that it does not match. |
102 ↗ | (On Diff #20723) | Also, this was tested in the whole diff. As only one element struct are supported now, I could write a test, but that would be very redundant with what already exists in D7607 . |
Add assert to check size match.
Rebase and update load test (as load syntax changed).
lib/Transforms/Scalar/AggregateMemAccessRemoval.cpp | ||
---|---|---|
102 ↗ | (On Diff #20723) | I don't like the approach "commit and fix in a separate change", unless there is a good reason and the "change" is already ready to follow. This is not a good process, and it build technical debt. Please do it right before committing. Recursion is never a good idea unless you can prove that you won't explode the stack. LLVM is used in embedded environment where the stack size is limited. Even on a regular PC, you don't want to crash because you have a very long sequence of instruction and you recurse blindly. |
lib/Transforms/Scalar/AggregateMemAccessRemoval.cpp | ||
---|---|---|
102 ↗ | (On Diff #20723) | Well ok but: |
- Rebase
- Create load and store with align directly instead of adding it later.
- Add comment about the recursion
Move all the things to InstCombine. Also, limit myself to store, as to keep thing minimal while we agree on the design.
I'm okay with what's here once my fairly minor comments are addressed, but let's wait for Chandler to take a look as well.
(And thank you again for sticking it through a long review process!)
lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp | ||
---|---|---|
811 | Rather than returning bool, please return the new Instruction or nullptr. This will allow us to add that new instruction to the worklist and will solve the deeply nested struct thing you were trying to address with recursion in the previous patch. Alternatively, you could simple add the newly created store to the worklist within this function. I have no strong preference, but I suspect Chandler may care. It might be good to let him comment before actually making either change. | |
816 | nit: Value *V You should probably run this through clang-format. | |
825 | Add a comment here that highlights the fact that the wrapped value can be smaller than the FCA and that we are possibly loosing dereferencability information here. We're okay with that for now, but it would be good to have it documented. | |
test/Transforms/InstCombine/aggregate-store.ll | ||
15 | Once you get the new stores onto the worklist, please add a test case for the nested struct case. |
lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp | ||
---|---|---|
811 | None of this is not required, the builder sue a custom inserted that do it already. As for the bool return, I followed convention existing in the file. | |
825 | It does not appear to be possible in the case where we have struct with one element. |
Rebase
Friendly ping as the last requested update was done late on friday, so most likely is lost deep down in everybody's queue at this point.
lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp | ||
---|---|---|
811 | I forgot about the custom inserter and the surrounding code appears to use a mixture of implicit and explicit adds. Comment withdrawn. | |
825 | Ok. I haven't thought about this hard, but this seems likely to be true. Even if not, it's not a big deal at the moment. |
LGTM, feel free to commit.
One nit, I would name the test case just "fca-decomposition" or something so we can add both load and store test cases to a single file.
arc land
Is telling me that I can't land and
git svn dcommit
Ask me for my password (which ?). I've been through http://llvm.org/docs/Phabricator.html but couldn't find what i was looking for. What is the expected setup ?
lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp | ||
---|---|---|
822 | Please write this as StructType *ST |
Rather than returning bool, please return the new Instruction or nullptr. This will allow us to add that new instruction to the worklist and will solve the deeply nested struct thing you were trying to address with recursion in the previous patch.
Alternatively, you could simple add the newly created store to the worklist within this function. I have no strong preference, but I suspect Chandler may care. It might be good to let him comment before actually making either change.