search for: multiprecision

I suggest that LLVM needs intrinsics for add/sub with carry, e.g. declare {T, i1} @llvm.addc.T(T %a, T %b, i1 c) The current multiprecision clang intrinsics example: void foo(unsigned *x, unsigned *y, unsigned *z) { unsigned carryin = 0; unsigned carryout; z[0] = __builtin_addc(x[0], y[0], carryin, &carryout); carryin = carryout; z[1] = __builtin_addc(x[1], y[1], carryin, &carryout); carryin = carryout;...

Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Why do you think this requires new intrinsics instead of teaching the optimizer what to do with the existing intrinsics? IMO, as a multiprecision math library maker, the "teaching the optimizer what to do with the existing intrinsics" approach is much better as long as it can be made to work. If one is careful, MSVC does optimize its intrinsics into ADC instructions in a reasonable way, so I think it is probably doable. (Below, al...

Do you have plans to add other intrinsics? I'm curious as to why there is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan intrinsic. Why is there an llvm.pow intrinsic but no llvm.log intrinsic? Also, have you thought about integer intrinsics like multiprecision multiply (u32xu32->u64) and multiprecision divide (u64/u32->(dividend:u32,remainder:u32))? Regards, Jon

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered

It takes two "llvm.uadd.with.overflow" instances to model the add-with-carry when there is a carry-in. Look at the IR generated by the example. I figured that the optimization of this would bedifficult (else it would have already been done :-)). And would this optimization have to be done for every architecture? On 02/15/2017 04:28 PM, Stephen Canon wrote: > > Why do you think

...m-dev <llvm-dev at lists.llvm.org> wrote: > > I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am not aware of any way currently available to produce IR that will generate these nodes directly. But what is the use case? What IR pattern it would replace? — Mehdi > > On Fri, Feb 17, 2017 at 8:52 PM, Bagel via llvm-dev <llvm-dev at lists.llvm.org <ma...

Hi, I know there's been some talk about bignums already, this is similar to it, but not exactly the same. I'm currently using LLVM for my master thesis. The goal is to make a compiler for zero-knowledge proofs of knowledge protocols. This compiler should target embedded devices. There's a language called the protocol implementation language in which these protocols should be

...ke the compiler to as much work as possible for me, and I’m wondering if you know how to make clang (or gcc, for that matter) do some of this. So I have a couple of questions. If this is the wrong list to ask for LLVM+Clang questions, please point me to a better one :-) First, addition. I have multiprecision integer objects, and I’d like to add them component-wise (likewise, subtract, negate, mask…). For example: struct mp { int limb[8]; } __attribute__((aligned(32))) ; void add(struct mp *a, const struct mp *b, const struct mp *c) { for (int i=0; i<8; i++) a->limb[i] = b->limb[i] + c-...

...implementation : NROW <- function(x) if(is.array(x)||is.data.frame(x)) nrow(x) else length(x) NCOL <- function(x) if(is.array(x) && length(dim(x)) > 1L || is.data.frame(x)) ncol(x) else 1L only treats something as matrix when is.array(.) is true, which is not the case, e.g., for multiprecision matrices from package 'gmp' or for matrices from packages SparseM, Matrix or similar. Of course, all these packages could write methods for NROW, NCOL for their specific matrix class, but given that the current definition is so simple, I'd find it an unnecessary complication. Rather I...

...ions to combine where wide multiplications are available on the chip? c) I want to ask something about retrieving the carry or borrow from an addition or subtraction and using it in an ADC or SBB..... not sure what to ask..... d) Are you guys at all interested in supporting languages that provide multiprecision arithmetic? I have a vague notion that I'd like to sign on to help with that (and may be able to bring some other experienced devels with me if there was some interest). I did see APInt and understand the necessity of such a library for constant folding etc. but my questions aren't specifi...

I'm trying to work out LLVM code which generates something similar to the following when adding large multiword numbers stored as separate words: ADD x1 x1 ADC x2 y2 ADC x3 y3 etc, where such a three argument add like ADC on x86 (which includes a carry in the addition) is available as a machine op. The background to this is that I'm trying to implement fast multiword addition in

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

...to ask..... >> >> LLVM automatically expands wide addition/subtraction with ADC/SBB. >> There's no other general way to write something which optimizes to an >> ADC/SBB, at least at the moment.  What do you want here? > > I should take a look at what happens for a multiprecision > addition/subtraction before I answer that one. I merely assumed that > this also only worked up to 128 bits on x86_64 as per multiplication. It should work at any width (although once you get to extremely wide integers, the number of spills makes the code get messy). Also, this isn't...

...gt; I come back to this older thread. > > As I've said before, I managed to patch the various files from the > back end related to lanemask in order to support at most 1024 vector > lanes. For this I am using a 1024-bit long lanemask of type uint1024_t > from boost::multiprecision, instead of uint32_t. For this I changed the > following LLVM source files: > [repository]/llvm/utils/TableGen/CodeGenRegisters.cpp > [repository]/llvm/utils/TableGen/CodeGenRegisters.h > [repository]/llvm/utils/TableGen/RegisterInfoEmitter.cpp > [reposit...

Hello. I come back to this older thread. As I've said before, I managed to patch the various files from the back end related to lanemask in order to support at most 1024 vector lanes. For this I am using a 1024-bit long lanemask of type uint1024_t from boost::multiprecision, instead of uint32_t. For this I changed the following LLVM source files: [repository]/llvm/utils/TableGen/CodeGenRegisters.cpp [repository]/llvm/utils/TableGen/CodeGenRegisters.h [repository]/llvm/utils/TableGen/RegisterInfoEmitter.cpp [repository]/llvm/lib/CodeGen/Tar...

...; >>> LLVM automatically expands wide addition/subtraction with ADC/SBB. >>> There's no other general way to write something which optimizes to an >>> ADC/SBB, at least at the moment.  What do you want here? >> >> I should take a look at what happens for a multiprecision >> addition/subtraction before I answer that one. I merely assumed that >> this also only worked up to 128 bits on x86_64 as per multiplication. > > It should work at any width (although once you get to extremely wide > integers, the number of spills makes the code get messy)....

On Feb 17, 2014, at 6:38 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Feb 17, 2014, at 8:10 PM, Michael Hamburg <mike at shiftleft.org> wrote: > >> First, addition. I have multiprecision integer objects, and I’d like to add them component-wise (likewise, subtract, negate, mask…). For example: >> >> struct mp { >> int limb[8]; >> } __attribute__((aligned(32))) ; >> >> void add(struct mp *a, const struct mp *b, const struct mp *c) { >>...

...NE)? In regards to libraries $ ldd /usr/lib/dovecot/imap-login | grep ssl libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f1f55025000) $ dpkg -l | grep ssl ii libcrypt-openssl-bignum-perl 0.04-3 amd64 Access OpenSSL multiprecision integer arithmetic libraries ii libcrypt-openssl-dsa-perl 0.13-6 amd64 module which implements the DSA signature verification system ii libcrypt-openssl-rsa-perl 0.28-1 amd64 module for RSA encryption using...

Hello. I've managed to patch the various files from the back end related to lanemask - now I have 1024-bit long lanemask. But now I get the following error when giving make llc: <<error:unhandled vector type width in intrinsic!>> This error comes from this file https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp, comes from the