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.