search for: umulh

Hi, For some maybe dumb reasons I try to write a portable version of int128. What is very valuable for this implementation is access to MUL instruction on x86 which provides full 64 x 64 -> 128 bit multiplication. An equally useful on ARM would be UMULH instruction. Well, the way you can access this on clang / GCC is to use __int128 type or use inline assembly. MSVC provides an intrinsic for this instruction. This defeats the idea of portable int128 reimplementation and makes constexpr implementation of multiplication at least inconvenient. Mayb...

...gt;> >> For some maybe dumb reasons I try to write a portable version of int128. >> >> What is very valuable for this implementation is access to MUL >> instruction on x86 which provides full 64 x 64 -> 128 bit multiplication. >> An equally useful on ARM would be UMULH instruction. >> >> Well, the way you can access this on clang / GCC is to use __int128 type >> or use inline assembly. MSVC provides an intrinsic for this instruction. >> This defeats the idea of portable int128 reimplementation and makes >> constexpr implementation of...

...and update the intrinsic ID, but I can't find an obvious place to put that code. I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is a switch statement on the first letter of the intrinsic name plus a long series of if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return Intrinsic::alpha_umulh; if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return Intrinsic::annotation; if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return Intrinsic::arm_neon_vabals; ... There has to be a mor...

Any takers? This patch improves on the previous one by making getIntrinsicID() inline. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091017/9406e0ad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: FastIntrinsicID-2.patch Type:

...and update the intrinsic ID, but I can't find an obvious place to put that code. I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is a switch statement on the first letter of the intrinsic name plus a long series of if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return Intrinsic::alpha_umulh; if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return Intrinsic::annotation; if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return Intrinsic::arm_neon_vabals; ... There has to be a mor...

...OperandList and InOperandList), but what about Ra? Ra contributes to defining the bits in Inst, and because there is, by default, no overlap checking, it also gets mapped to the first operand: GPR64:$Rd. The result, from AArch64GenMCCodeEmitter.inc is: case AArch64::SMULHxxx: case AArch64::UMULHxxx: { // op: Rd op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); Value |= op & UINT64_C(31); // op: Rn op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI); Value |= (op & UINT64_C(31)) << 5; // op: Rm op = getMachineOpVal...