================
@@ -1469,6 +1465,47 @@ void VPReplicateRecipe::print(raw_ostream &O, const
Twine &Indent,
}
#endif
+Value *VPScalarCastRecipe ::generate(VPTransformState &State, unsigned Part) {
+ assert(vputils::onlyFirstLaneUsed(this) &&
+ "Codegen only implemented for first lane only.");
+ switch (Opcode) {
+ case Instruction::SExt:
+ case Instruction::ZExt:
+ case Instruction::Trunc: {
+ Value *Op = State.get(getOperand(0), VPIteration(Part, 0));
+ return State.Builder.CreateCast(Instruction::CastOps(Opcode), Op,
ResultTy);
+ }
+ default:
+ llvm_unreachable("opcode not implemented yet");
+ }
+}
+
+void VPScalarCastRecipe ::execute(VPTransformState &State) {
+ bool UniformAcrossUFs = all_of(operands(), [](VPValue *Op) {
+ return Op->isDefinedOutsideVectorRegions();
+ });
+ for (unsigned Part = 0; Part != State.UF; ++Part) {
+ Value *Res;
+ // Only generate a single instance, if the recipe is uniform across all
UFs.
----------------
ayalz wrote:
This is currently untested / dead code.
The value returned by an EVL recipe should arguably be of the same type as that
of its first operand, even if the underlying intrinsic it currently wraps
insists on always returning an i32? I.e., that case should arguably be fixed by
performing a trunc/sext/zext as needed when providing the adequate EVL value
given a current Phi/remaining-trip-count values, to facilitate
adding/subtracting them together.
https://github.com/llvm/llvm-project/pull/78113
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
