Commit
7fea561eb1ce0a339f3c47f6d89d2e9fa8706ab0
by aeubanks[CGSCC][Coroutine][NewPM] Properly support function splitting/outlining
Previously when trying to support CoroSplit's function splitting, we added in a hack that simply added the new function's node into the original function's SCC (https://reviews.llvm.org/D87798). This is incorrect since it might be in its own SCC.
Now, more similar to the previous design, we have callers explicitly notify the LazyCallGraph that a function has been split out from another one.
In order to properly support CoroSplit, there are two ways functions can be split out.
One is the normal expected "outlining" of one function into a new one. The new function may only contain references to other functions that the original did. The original function must reference the new function. The new function may reference the original function, which can result in the new function being in the same SCC as the original function. The weird case is when the original function indirectly references the new function, but the new function directly calls the original function, resulting in the new SCC being a parent of the original function's SCC. This form of function splitting works with CoroSplit's Switch ABI.
The second way of splitting is more specific to CoroSplit. CoroSplit's Retcon and Async ABIs split the original function into multiple functions that all reference each other and are referenced by the original function. In order to keep the LazyCallGraph in a valid state, all new functions must be processed together, else some nodes won't be populated. To keep things simple, this only supports the case where all new edges are ref edges, and every new function references every other new function. There can be a reference back from any new function to the original function, putting all functions in the same RefSCC.
This also adds asserts that all nodes in a (Ref)SCC can reach all other nodes to prevent future incorrect hacks.
The original hacks in https://reviews.llvm.org/D87798 are no longer necessary since all new functions should have been registered before calling updateCGAndAnalysisManagerForPass.
This fixes all coroutine tests when opt's -enable-new-pm is true by default. This also fixes PR48190, which was likely due to the previous hack breaking SCC invariants.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D93828
|
 | llvm/lib/Analysis/LazyCallGraph.cpp |
 | llvm/test/Transforms/Coroutines/coro-split-recursive.ll |
 | llvm/lib/Transforms/Utils/CallGraphUpdater.cpp |
 | llvm/lib/Analysis/CGSCCPassManager.cpp |
 | llvm/include/llvm/Transforms/Utils/CallGraphUpdater.h |
 | llvm/lib/Transforms/Coroutines/CoroSplit.cpp |
 | llvm/unittests/Analysis/CGSCCPassManagerTest.cpp |
 | llvm/lib/Transforms/IPO/OpenMPOpt.cpp |
 | llvm/unittests/Analysis/LazyCallGraphTest.cpp |
 | llvm/include/llvm/Analysis/LazyCallGraph.h |
 | llvm/test/Transforms/Coroutines/coro-async.ll |
 | llvm/test/Transforms/Coroutines/coro-retcon-resume-values2.ll |
Commit
5d24089a7001e9fb4c0e665e93312916d88aaef9
by spatel[SLP] reduce code for propagating flags on reductions; NFC
If we add/change to match intrinsics, this might get more wordy, but there's no need to list each kind currently.
|
 | llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp |
Commit
4c022b5a41dee998ae50cdad4e8b6548acbeee9f
by spatel[SLP] use reduction kind's opcode to create new instructions; NFC
Similar to 5a1d31a28 - This should be no-functional-change because the reduction kind opcodes are 1-for-1 mappings to the instructions we are matching as reductions. But we want to remove the need for the `OperationData` opcode field because that does not work when we start matching intrinsics (eg, maxnum) as reduction candidates.
|
 | llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp |
Commit
8f9da24fa7fffd52ccc2c66e3e2c1e7e87ed0336
by nikita.ppv[GVN] Regenerate test checks (NFC)
|
 | llvm/test/Transforms/GVN/PRE/volatile.ll |
Commit
a6df39236fdc6e422f6794935e5e08e05f566e23
by nikita.ppv[InstSimplify] Fold out-of-bounds shift to poison
Make InstSimplify return poison rather than undef for out-of-bounds shifts, as specified by LandRef:
> If op2 is (statically or dynamically) equal to or larger than the > number of bits in op1, this instruction returns a poison value.
Differential Revision: https://reviews.llvm.org/D93998
|
 | llvm/lib/Analysis/InstructionSimplify.cpp |
 | llvm/test/Transforms/InstSimplify/shift-knownbits.ll |
 | llvm/test/Transforms/InstCombine/phi-shifts.ll |
 | llvm/test/Transforms/InstSimplify/undef.ll |
 | llvm/test/Transforms/InstCombine/out-of-bounds-indexes.ll |
 | llvm/test/Transforms/InstSimplify/shift.ll |
 | llvm/test/Transforms/InstCombine/add-shl-sdiv-to-srem.ll |
 | llvm/test/Transforms/InstCombine/shift.ll |
Commit
54c01057b68d2a0e565f289cfa9edb8cca7f5980
by aeubanksFix non-assert builds after D93828
|
 | llvm/lib/Analysis/LazyCallGraph.cpp |
Commit
a515342de9c578ed2d9b5414be008ca4a876c903
by aeubanks[test] Pin AMDGPU/opt-pipeline.ll to legacy PM
The pipeline being tested is specifically the legacy PM pipeline.
|
 | llvm/test/CodeGen/AMDGPU/opt-pipeline.ll |
Commit
c68faed041e664be5b289eae00ee4ca855ddf1c9
by craig.topper[RISCV] Return a vXi1 vector type from getSetCCResultType if V extension is enabled.
nvxXi1 types are legal with V extension and that's the result vmseq/vmsne/vmslt/etc instructions return.
No test cases yet because the setcc isel patterns aren't in and we'll need more than basic tests to observe this. I locally tested that this plus D947078, D94168, D94142, and D94149 was enough to be able to handle the overflow result from llvm.sadd.overflow.
|
 | llvm/lib/Target/RISCV/RISCVISelLowering.cpp |
Commit
47fba9e1eae63fa30c9f9a7d9ca42e694ba74b0a
by aeubanks[test] Pin partial-unswitch.ll to legacy PM
The new PM does not have loop-unswitch, it only has simple-loop-unswitch.
|
 | llvm/test/Transforms/LoopUnswitch/partial-unswitch.ll |