diff options
| author | Florian Hahn <flo@fhahn.com> | 2025-10-13 11:16:14 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-10-13 11:16:14 +0100 |
| commit | 9bb0eedb59b9a2c4a2e1d2e9f87d1ecf836f70da (patch) | |
| tree | 0ae60c2e59e44744ab7aeb73b20a60fb37bbadc5 /llvm/lib/Object/Object.cpp | |
| parent | 946238e74866524466bb98bb75e54577c6fa3e85 (diff) | |
| download | llvm-9bb0eedb59b9a2c4a2e1d2e9f87d1ecf836f70da.zip llvm-9bb0eedb59b9a2c4a2e1d2e9f87d1ecf836f70da.tar.gz llvm-9bb0eedb59b9a2c4a2e1d2e9f87d1ecf836f70da.tar.bz2 | |
[VPlan] Assign custom opcodes to recipes not mapping to IR opcodes. (#162267)
We can perform CSE on recipes that do not directly map to Instruction
opcodes. One example is VPVectorPointerRecipe. Currently this is handled
by supporting them in ::canHandle, but currently that means that we
return std::nullopt from getOpcodeOrIntrinsicID() for it. This currently
only works, because the only case we return std::nullopt and perform CSE
is VPVectorPointerRecipe. But that does not work if we support more such
recipes, like VPPredInstPHIRecipe
(https://github.com/llvm/llvm-project/pull/162110).
To fix this, return a custom opcode from getOpcodeOrIntrinsicID for
recipes like VPVectorPointerRecipe, using the VPDefID after all regular
instruction opcodes.
PR: https://github.com/llvm/llvm-project/pull/162267
Diffstat (limited to 'llvm/lib/Object/Object.cpp')
0 files changed, 0 insertions, 0 deletions
