This patch makes code motion checks optional which are dependent on specific analysis example, dominator tree, post dominator tree and dependence info. The aim is to make the adoption of CodeMoverUtils easier for clients that don't use analysis which were strictly required by CodeMoverUtils. This will also help in diversifying code motion checks using other analysis example MSSA.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Scalar/LoopFuse.cpp | ||
---|---|---|
513 | where is no need to change LoopFuse, just pass the address when calling the APIs. | |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
100 | you can a segfault here when DT is nullptr, making analyses optional means you have to add handle when they are nullptr, and add alternative ways to do what the function is intended to do. | |
320 | so as long as DT is nullptr, instruction is safe to move before InsertPoint? can return false here instead of true. |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
---|---|---|
100 | in that case change the parameters back to references for ControlConditions |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
---|---|---|
100 | Thanks, updated. |
llvm/include/llvm/Transforms/Utils/CodeMoverUtils.h | ||
---|---|---|
29–30 | what's the reason why some arguments have nullptr as default value, and some doesn't? | |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
226–227 | Is there an alternative way to check control flow equivalent without DT and PDT? If not, change it back to references. | |
231–232 | here you are dereferencing a pointer that can be a nullptr. | |
320 | Actually if DI or PDT or DI, either one is nullptr, than this function never return true, so why not just check that in the beginning. | |
366 | return false | |
374 | return false | |
llvm/unittests/Transforms/Utils/CodeMoverUtilsTest.cpp | ||
33–34 | I prefer not to change any of the parameters from references to pointers, just change the call site. |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
---|---|---|
320 | I understood your point. Say we don't have DT, PDT or DI then instead of returning false should we return true/false based on our best knowledge? If a client don't have DT, PDT and DI then it may be expecting at least some checks (which may or may not be of any real use)? Also, when we will add more analysis (example MSSA) then would it make more sense to return true/false based on whatever checks/analysis we have with us and not conservatively returning false? |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
---|---|---|
320 | If DT, PDT, or DI is nullptr, we have to conservatively return false, we can only say is safe to move before if we are sure it is safe. If we have more analysis, for example MSSA, and it can tell if the instruction is for sure safe to move, then we can return true in that case. Does it make sense? |
llvm/lib/Transforms/Utils/CodeMoverUtils.cpp | ||
---|---|---|
320 | Yes it does, Updated. |
what's the reason why some arguments have nullptr as default value, and some doesn't?