Upstream the inliner and do_loop rewriter passes. This diff starts the process of upstreaming some of the FIR transformation passes to llvm-project.
Details
Diff Detail
Event Timeline
flang/include/flang/Optimizer/Transforms/Passes.td | ||
---|---|---|
22 | Is the a pro forma description that could be added? |
Stupid question perhaps, but if they are two passes, shouldn't they be added in two commits?
In the passes files there are 6 pass creators declared. I failed to find all the definitions in this patch.
It seems sensible to split this into multiple commits. I would also recommend tests for new functionality.
[EDIT: Took too long to write my comments, seems abandoned now]
flang/include/flang/Optimizer/Transforms/Passes.td | ||
---|---|---|
22 | Yes, please. | |
flang/lib/Optimizer/Transforms/Inliner.cpp | ||
35 | I would suggest to make the inliner pass a no-op if it is disabled. I can also see that the enable flag will prevent it from being put in the pipeline but disabling the create function here with a comment suggesting there is a hidden dependence to another function seems fragile. It is also counter-intuitive to people that have seen llvm::createXXXPass functions before. | |
flang/lib/Optimizer/Transforms/RewriteLoop.cpp | ||
84 | There seems little reason to commit dead code. |
This is the nature of this process we're on. We're being asked to upstream tiny bits with each diff, the smaller the better. The reality is that however one slices it, the code will always be interrelated. In order to keep the diffs small, some sort of compromise must be made.
flang/lib/Optimizer/Transforms/RewriteLoop.cpp | ||
---|---|---|
84 | I agree that this can be cleaned up. I disagree in that we will be upstreaming code with TODOs in the short term. The only other approach is to wait until flang is a final polished product, which would make it awkward for the LLVM community as a whole to contribute. |
This is the nature of this process we're on. We're being asked to upstream tiny bits with each diff, the smaller the better. The reality is that however one slices it, the code will always be interrelated. In order to keep the diffs small, some sort of compromise must be made
How about series/chain of patches filed together with dependencies[Parent-Child] specified ? This could help in review/tracking process.
clang-tidy: warning: header guard does not follow preferred style [llvm-header-guard]
not useful