The arguments to a PHI may represent a recurrence by eventually using the output
of the PHI itself. This is now handled by checking for cycles in the control
flow. If a PHI is not in a recurrence, it is now able to report multiple offsets
instead of conservatively reporting unknown.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | Do we really need legacy PM support? I would prefer not to add complexity for it. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | Yes. Contrary to popular belief, the new PM is not complete. Until we have codegen support, we need legacy PM support for IR passes run in the backend |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | is it possible to run whatever pass you're interested in as part of the optimization pipeline? |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | Not in the right place. We can't even move all the IR passes because of the one RegionPass which new PM doesn't have. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | Shouldn't we invest the time and code to provide a "region pass wrapper"? We stopped testing most of these things with the old PM, using it is not a great idea. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | We should invest the time in killing of the structurizer entirely. It being a region pass is a problem for many reasons. But that's hard |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 | @arsenm Where do I find that structurizer and what should the replacement do/look like? It's not https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Scalar/StructurizeCFG.cpp right? |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
1131 |
llvm/test/CodeGen/AMDGPU/implicitarg-attributes.ll | ||
---|---|---|
66 | I rather dislike CHECK-NOT checks for their fragility, and it's best to be as vague as possible. Probably should remove the .value_kind |
Do we really need legacy PM support? I would prefer not to add complexity for it.