[llvm-dev] [cfe-dev] Portable multiplication 64 x 64 -> 128 for int128 reimplementation

[Craig Topper via llvm-dev]

_mulx_u64 only exists when the target is x86_64. That's still not very
portable. I'm not opposed to removing the bmi2 check, but gcc also has the
same check so it doesn't improve portability much.

~Craig


On Sat, Dec 29, 2018 at 4:44 PM Arthur O'Dwyer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Pawel,
>
> There is the _mulx_u64 intrinsic, but it currently requires the hardware
> flag "-mbmi2".
>
> https://github.com/Quuxplusone/WideIntProofOfConcept/blob/master/wider.h#L89-L99
>
> On Clang 3.8.1 and earlier, the _addcarry_u64 and _subborrow_u64
> intrinsics required the hardware flag `-madx`, even though they didn't use
> the hardware ADX/ADOX instructions. Modern GCC and Clang permit the use of
> these intrinsics (to generate ADC) even in the absence of `-madx`.
>
> I think it would be a very good idea for Clang to support _mulx_u64 (to
> generate MUL) even in the absence of `-mbmi2`.
>
> –Arthur
>
>
> On Sat, Dec 29, 2018 at 6:03 PM Paweł Bylica via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> Maybe there is a hope for me in LLVM. Is there any pattern matcher that
>> is producing MUL instruction of bigger type?
>> If not, would it be good idea to teach LLVM about it?
>>
>> Bests,
>> Paweł
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181229/fc8f9f4e/attachment.html>