search for: int128

Thanks for the quick reply. Yes, passing it as int128* is a workaround that obviously works. Still, that leaves me with the return values. Or are you suggesting that I rewrite int128 Modify(int128& tmp) { … } to void Modify(int128& result, int128& tmp) { … } Obviously that will work, it just feels… dirty and wrong… :-) I’ve also attem...

The Windows x64 ABI rules say that anything larger than 8 bytes is passed by reference.[1] Because MSVC doesn't support the __int128 type on x64, nobody has made sure that the LLVM i128 type is passed in a way that follows the local ABI rules. I think LLVM should probably pass i128 the same way it passes <2 x i64> on Win64, which is indirectly in memory. Until LLVM is fixed, you can work around the problem by passing i128...

On Wed, Dec 21, 2016 at 11:18 AM, Stefan de Bruijn <stefan at nubilosoft.com> wrote: > Thanks for the quick reply. Yes, passing it as int128* is a workaround > that obviously works. Still, that leaves me with the return values. Or are > you suggesting that I rewrite > > > > int128 Modify(int128& tmp) { … } > > > > to > > > > void Modify(int128& result, int128& tmp) { … } > > &g...

...g to call a C++ function from LLVM code. The LLVM code is JIT'ted and executed from C++. Basically my idea was as follows: -- LLVM IR code - ; ModuleID = 'native' define i32 @main(i32, i8**) { code: call void @"Helper::Test"(i128 128932) ret i32 0 -- C++ code - struct int128 { uint64_t v1; uint64_t v2; // ... code omitted... *1 }; struct Helper { static void Test(int128 value) { } }; If I try to execute the code, I notice that MSVC++ seems to expect a pointer. Most notably, if you implement the copy constructor: int128(const int128...

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 p...

...intrinsic `_umul128 > <https://docs.microsoft.com/en-us/cpp/intrinsics/umul128?view=vs-2017>`, > and on MSVC it does generate a regular MUL instruction rather than forcing > MULX. > > > Anyway, I want to go the opposite direction. [...] mulx() helper without >> using __int128 type in a way that a compiler would recognize that it should >> use MUL/MULX instruction. >> A possible implementation looks like [SNIPPED] >> > > Interesting trivia: There are at least three ways to write the final > "return" statement in this function. Clang g...

...x_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...

...e bottom of the function (with the division & > > comparison of the quotient against INT_MAX) will work just the same. > > I'm always very unsure how this all works. In particular I seem to > recall that intmax_t is no longer really the maximum possible int > (because of int128) and so it's always 64 bit on platforms we care > about. Can Eric comment? intmax_t was supposed to be whatever the compiler supports as its largest integer type; but you are right that when gcc added __int128_t, they did NOT change intmax_t at the time (arguably by using weasel-words that...

...r the stackmap and patchpoint intrinsics. [r326611](http://reviews.llvm.org/rL326611). ## Clang commits * Initial ('naive') support for cross translation unit analysis with the Clang Static Analyzer has been added. [r326323](http://reviews.llvm.org/rL326323). * The flags `-fforce-enable-int128` and `-fno-force-enable-int128` were added to 'force' support for `__int128_t` and `__uint128_t` for a target. [r326045](http://reviews.llvm.org/rL326045). * A heuristic was added so the static analyzer skips yacc/bison-generated files. [r326135](http://reviews.llvm.org/rL326135). ## Oth...

Hi Team, I observer that division of __int128 bit is very heavy operation. It internally call a routine '__udivti3', which internally call ' __udivmodti4'. Due to it the overall performance is much much slower (almost 15 time slower than if I do it via a combination of 64-bit or microsoft '_udiv128'). Also what to kno...

I’m trying to figure out how to build compiler-rt 3.5.0 with Visual Studio 2013. In an autotools build or cmake on Linux, I believe putting the compiler-rt sources under llvm/projects is enough to build them automatically. Do I need to do anything specific to get the same with MSVC? I've tried setting -DLLVM_BUILD_EXTERNAL_COMPILER_RT either ON or OFF, but can't find any evidence of

On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote: > > Part of me is still concerned with the future, and the filesystems which are yet to exist. > Me too. But it is best to target modern systems when targeting future systems adds an unnecessary cost. When future systems come into being, it is likely because future hardware is making those future systems

...gt; - Reaching the end of a function with a non-void return type, in C++ (in C, this is only UB if the caller uses the return value) > - Overflow in conversion from floating point to smaller floating point or to integral type > - Overflow in conversion from integral type to floating point (int128 to float, or when converting to __fp16) > - Converting an out-of-range integer to an enumerated type > - Floating-point arithmetic overflow > - Pointer arithmetic which leaves the bounds which can be determined by llvm.objectsize > - Pointer subtraction between pointers which can be...

...clarationName and the StringRef. > (Umesh Kalappa via llvm-dev) > 8. convert load with load from getElementPtr > (Varun Patil via llvm-dev) > 9. Re: convert load with load from getElementPtr > (Mehdi Amini via llvm-dev) > 10. Re: Correct way to pass int128 from LLVM to C++ function > (MSVC) (Stefan de Bruijn via llvm-dev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Dec 2016 15:13:40 -0800 > From: Jingyue Wu via llvm-dev <llvm-dev at lists.llvm.org> &g...

I am pleased to announce that LLVM 10 is now available. Get it here: https://llvm.org/releases/download.html#10.0.0 This release is the result of the LLVM community's work over the past six months (up to to e26a78e7085 on master plus commits up to d32170dbd5b on the release/10.x branch). Some highlights include: - C++ Concepts support in Clang - Clang no longer runs in a separate process

I am pleased to announce that LLVM 10 is now available. Get it here: https://llvm.org/releases/download.html#10.0.0 This release is the result of the LLVM community's work over the past six months (up to to e26a78e7085 on master plus commits up to d32170dbd5b on the release/10.x branch). Some highlights include: - C++ Concepts support in Clang - Clang no longer runs in a separate process

...igh 64 bits >> of a 64x64 bit multiply. I don't think this is done, or done >> efficiently in LLVM currently. Or I might be missing something. > > Should work the same as the previous example; try the following on x86-64: > long long a(long long x, long long y) { return ((__int128_t)x)*y >> 64; } Ah, I looked for this last night for some time. I tried uint128_t, u_int128_t, uint128, int128, everything you can imagine... except of course .... that. Should've read the manual. Damn, it does do this in one mul for unsigned multiplication! I feel embarrassed now. The...

Hello everyone, Release Candidate 4 was tagged earlier today as llvmorg-10.0.0-rc4 on the release branch at b406eab8880. It contains 12 commits since the previous release candidate. If no new problems arise, this is what the final release will look like. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc4 and

Hello again, I had hoped that rc4 would be the last one, but I wanted to pick up one more fix, so here we go. Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the release branch at 35627038123. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc5 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5 If nothing new comes up, I plan to tag

Hi all, After searching for a decent compiler backend for ages (google sometimes isn't helpful), I recently stumbled upon LLVM. Woot!! I work on bignum arithmetic (I'm a professional mathematician) and have recently decided to switch from developing GPL'd bignum code to BSD licensed code. (See http://www.mpir.org/ which I contributed to for a while - a fork of GMP). Please bear with