<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sun, Dec 30, 2018 at 4:46 PM Paweł Bylica <<a href="mailto:chfast@gmail.com">chfast@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Arthur, Craig,<div><br></div><div>Thanks for you comments about GCC/Clang intrinsics. I never considered using them, but they might be better alternative to inline assembly.<br>Is there a one for regular MUL?<br></div></div></div></blockquote><div><br></div><div>I'm not sure, but I think there currently does not exist any intrinsic to generate the top half of a 64x64=128 multiply, except for `_mulx_64`.<br></div><div>If Clang stopped requiring `-mbmi2`, I would then expect the `_mulx_64` intrinsic to generate a regular MUL instruction; similar to how_addcarry_u64 generates ADCX/ADOX when available/useful and a regular ADC otherwise.</div><div>MSVC calls this intrinsic `<a href="https://docs.microsoft.com/en-us/cpp/intrinsics/umul128?view=vs-2017">_umul128</a>`, and on MSVC it does generate a regular MUL instruction rather than forcing MULX.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Anyway, I want to go the opposite direction. [...] <span style="background-color:rgb(255,255,254)">mulx() helper without using __int128 type in a way that a compiler would recognize that it should use MUL/MULX instruction.</span><div style="background-color:rgb(255,255,254)"><div>A possible implementation looks like [SNIPPED]</div></div></div></div></div></blockquote><div> </div><div>Interesting trivia: There are at least three ways to write the final "return" statement in this function. Clang generates different code for each one of them. If someone does pursue writing an InstCombine optimization for this, it would be good to generate the same efficient code for all three versions.</div><div><a href="https://godbolt.org/z/-Cozee">https://godbolt.org/z/-Cozee</a> (LLVM IR: <a href="https://godbolt.org/z/_1pDoz">https://godbolt.org/z/_1pDoz</a>)</div><div><br></div><div>–Arthur</div></div></div></div></div></div></div></div></div>