As it turns out, whether we zero-extend or sign-extend i8/i16 constants, which
are illegal types promoted to i32 on PowerPC, is a choice constrained by
assumptions within the infrastructure. Specifically, the logic in
FunctionLoweringInfo::ComputePHILiveOutRegInfo assumes that constant PHI
operands will be zero extended, and so, at least when materializing constants
that are PHI operands, we must do the same.
The rest of our fast-isel implementation does not appear to depend on the fact
that we were sign-extending i8/i16 constants, and all other targets also appear
to zero-extend small-bitwidth constants in fast-isel; we'll now do the same (we
had been doing this only for i1 constants, and sign-extending the others).
Fixes PR27721.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280614
91177308-0d34-0410-b5e6-
96231b3b80d8
else if (const GlobalValue *GV = dyn_cast<GlobalValue>(C))
return PPCMaterializeGV(GV, VT);
else if (const ConstantInt *CI = dyn_cast<ConstantInt>(C))
- return PPCMaterializeInt(CI, VT, VT != MVT::i1);
+ // Note that the code in FunctionLoweringInfo::ComputePHILiveOutRegInfo
+ // assumes that constant PHI operands will be zero extended, and failure to
+ // match that assumption will cause problems if we sign extend here but
+ // some user of a PHI is in a block for which we fall back to full SDAG
+ // instruction selection.
+ return PPCMaterializeInt(CI, VT, false);
return 0;
}
; ELF64: t10
%call = call i32 @bar(i8 zeroext 0, i8 zeroext -8, i8 zeroext -69, i8 zeroext 28, i8 zeroext 40, i8 zeroext -70)
; ELF64: li 3, 0
-; ELF64: li 4, -8
-; ELF64: li 5, -69
+; ELF64: li 4, 248
+; ELF64: li 5, 187
; ELF64: li 6, 28
; ELF64: li 7, 40
-; ELF64: li 8, -70
+; ELF64: li 8, 186
; ELF64: rldicl 3, 3, 0, 56
; ELF64: rldicl 4, 4, 0, 56
; ELF64: rldicl 5, 5, 0, 56