[ARM] arm.codegen.zeroext intrinsics

[samparker]

Summary

Introduce two intrinsics which are then lowered in the backend to AssertZExt nodes. These can be inserted into the IR when the compiler knows that the given operand is already a zero extended i8 or i16.

[efriedma]

These clearly shouldn't be target-specific.

Usually, if there isn't loop involved, SelectionDAGBuilder can figure out leading zeros itself by using computeKnownBits on the live-out values. Are you sure you can't solve whatever issue you're looking at by improving ARMTargetLowering::computeKnownBitsForTargetNode?

[samparker]

Yes exactly, I would like to use these for loops. In ARMCodeGenPrepare I need to insert truncs to keep the IR legal, although I've already proved that the value is already zero extended. In those cases I want to use these intrinsics to carry that knowledge through. So it's not trying to work around the lack of info of target specific nodes. Another idea I wondered about was adding flags to instructions, but that seems far more intrusive.

[samparker]

And what would I need to do about testing for a generic intrinsic? Add to BitCode/compatibility-6.0.ll test and just keep this codegen one too?

[efriedma]

Add to BitCode/compatibility-6.0.ll test and just keep this codegen one too?

Yes, that's probably enough for basic testing...

But a portable intrinsic probably also needs to go through a design discussion on llvmdev, so it's clear this is the right design: how is this different from other similar constructs like !range metadata and llvm.assert, is there some way to communicate this information to SelectionDAG in some way that doesn't involve mutating the IR, how can we generalize this, etc.

Or maybe we could keep this target-specific, with a different name, with the justification that this isn't really an IR extension, just an implementation detail of the code generator to work around SelectionDAG limitations. We already have a sort of notion that when IR is passed to the code generator, the code generator can modify IR in ways that might not make sense to general IR passes. For example, llvm.ppc.mtctr is an intrinsic only used by PPCCTRLoops. But in that case we should use a name that makes it clear it isn't a general-purpose intrinsic usable by frontends or IR optimizations.

[samparker]

To try to make it clear that these are not user facing intrinsics, I've renamed them to arm.codegen.zeroext

include/llvm/IR/IntrinsicsARM.td

 
 let TargetPrefix = "arm" in {  // All intrinsics start with "llvm.arm.".
 
 // A space-consuming intrinsic primarily for testing ARMConstantIslands. The
 // first argument is the number of bytes this "instruction" takes up, the second
 // and return value are essentially chains, used to force ordering during ISel.
 def int_arm_space : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], []>;
 
+// Intrinsics for the compiler to use to assert that the operand is either a
+// i8 or i16 that is already zero extended.
+def int_arm_codegen_zeroext_i8 :
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty], [IntrNoMem]>;
+def int_arm_codegen_zeroext_i16 :
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty], [IntrNoMem]>;
+
 // 16-bit multiplications
 def int_arm_smulbb : GCCBuiltin<"__builtin_arm_smulbb">,
     Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrNoMem]>;
 def int_arm_smulbt : GCCBuiltin<"__builtin_arm_smulbt">,
     Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrNoMem]>;
 def int_arm_smultb : GCCBuiltin<"__builtin_arm_smultb">,
     Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrNoMem]>;
 def int_arm_smultt : GCCBuiltin<"__builtin_arm_smultt">,

lib/Target/ARM/ARMISelLowering.cpp

         MachinePointerInfo::getConstantPool(DAG.getMachineFunction()));
 
     if (IsPositionIndependent) {
       SDValue PICLabel = DAG.getConstant(ARMPCLabelIndex, dl, MVT::i32);
       Result = DAG.getNode(ARMISD::PIC_ADD, dl, PtrVT, Result, PICLabel);
     }
     return Result;
   }
+  case Intrinsic::arm_codegen_zeroext_i8:
+    return DAG.getNode(ISD::AssertZext, dl, MVT::i32, Op->getOperand(1),
+                       DAG.getValueType(MVT::i8));
+  case Intrinsic::arm_codegen_zeroext_i16:
+    return DAG.getNode(ISD::AssertZext, dl, MVT::i32, Op->getOperand(1),
+                       DAG.getValueType(MVT::i16));
   case Intrinsic::arm_neon_vabs:
     return DAG.getNode(ISD::ABS, SDLoc(Op), Op.getValueType(),
                         Op.getOperand(1));
   case Intrinsic::arm_neon_vmulls:
   case Intrinsic::arm_neon_vmullu: {
     unsigned NewOpc = (IntNo == Intrinsic::arm_neon_vmulls)
       ? ARMISD::VMULLs : ARMISD::VMULLu;
     return DAG.getNode(NewOpc, SDLoc(Op), Op.getValueType(),

test/CodeGen/ARM/codegen-zeroext-intrinsic.ll

+; RUN: llc -mtriple=armv8 %s -o - | FileCheck %s
+; RUN: llc -mtriple=thumbv8m.main %s -o - | FileCheck %s
+
+; CHECK-LABEL: zero_i8
+; CHECK-NOT: uxt
+; CHECK: bx
+define zeroext i8 @zero_i8(i32 %arg) {
+entry:
+  %zeroext = call i32 @llvm.arm.codegen.zeroext.i8(i32 %arg)
+  %trunc = trunc i32 %zeroext to i8
+  ret i8 %trunc
+}
+
+; CHECK-LABEL: zero_i8_mismatch
+; CHECK-NOT: uxt
+; CHECK: bx
+define zeroext i16 @zero_i8_mismatch(i32 %arg) {
+entry:
+  %zeroext = call i32 @llvm.arm.codegen.zeroext.i8(i32 %arg)
+  %trunc = trunc i32 %zeroext to i16
+  ret i16 %trunc
+}
+
+; CHECK-LABEL: zero_i16
+; CHECK-NOT: uxt
+; CHECK: bx
+define zeroext i16 @zero_i16(i32 %arg) {
+entry:
+  %zeroext = call i32 @llvm.arm.codegen.zeroext.i16(i32 %arg)
+  %trunc = trunc i32 %zeroext to i16
+  ret i16 %trunc
+}
+
+; CHECK-LABEL: zero_i16_mismatch
+; CHECK: uxtb r0, r0
+; CHECK: bx
+define zeroext i8 @zero_i16_mismatch(i32 %arg) {
+entry:
+  %zeroext = call i32 @llvm.arm.codegen.zeroext.i16(i32 %arg)
+  %trunc = trunc i32 %zeroext to i8
+  ret i8 %trunc
+}
+
+declare i32 @llvm.arm.codegen.zeroext.i8(i32)
+declare i32 @llvm.arm.codegen.zeroext.i16(i32)