similar to: [LLVMdev] Modular arithmetic processors

Hi, My personal opinion: Just to be sure I understand what you're considering: you want to write a backend that will produce optimized machine code for a device with modular arithmetic instructions (not simulate such a device on a standard CPU)? In which case, won't the same assumptions that are embodied in the transformations for the case of unsigned 2's complement arithmetic (in

Thanks for your insightful suggestions. Yes, I am programming for a real device that does modular arithmetic (and only modular arithmetic). The modulus N is fixed during a single launch of a program. One way I could also come up with is to simply use add i256 %a, %b to represent a + b mod n, and let LLVM passes to reason about possible optimizations. However these are not semantically identical

Hi, I'm using the '%%' operator in some code, and am running into the following erroneous outcome: > 1.2 %% 0.2 [1] 0.2 Unless I'm very mistaken, the result should be 0 (indeed, 12 %% 2 does result in 0). Furthermore: > 1.20000000000000001 %% 0.2 [1] 0.2 > (1.2+1e17) %% .2 [1] 0 Warning message: probable complete loss of accuracy in modulus (Warning

Hello List, I am on the hook to instrument a piece of legacy LLVM IR code, and then we are planning to feed to the SeaHorn framework for some model checking tasks. After the instrumentation, I tried to use llc (version 3.9) to compile the IR code, and it works fine. However, when I try to use llc (version 3.8.1, the default llvm version of SeaHorn) to compile the IR code, it shows the following

I want to find the inverse of an integer k mod p (prime.) Is there a function that can do this for me? I know i could simply write (k^(p-2)) %% p, but i need to do this for large primes (above 100) and this gives the warning message: Warning message: probable complete loss of accuracy in modulus so this method does not work. Any ideas? Thanks, Samuel --

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

Hi LLVM, This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate? 1. The pass transforms IR and is meant to be run before CodeGen (after IR optimizations). 2. The pass replaces

Hi, I have a small JIT project based on MCJIT. The generated LLVM IR code uses the i256 type. Also, the jitted code has to call back the host application from time to time. E.g. it calls a function i256 @callback(i256). 1. Can the callback function be implemented on the host application side (C/C++) to match the ABI used for the call by MCJIT? Or maybe the i256 has be to be casted to

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

On May 25, 2010, at 5:16 PM, Ehsan Amiri wrote: > Hello all > > I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. This works for me on mainline.

On Sep 5, 2008, at 3:07 PM, Duncan Sands wrote: > The current maximum the code generators support is i256. If you try > to > use bigger integers it will work fine in the bitcode, but if you try > to do code generation the compiler will crash. FYI, there is one other issue here, PR2660. While codegen in general can handle types like i256, individual targets don't always have

Hello everyone, After reading the nice blog post about _ExtInt, I was wondering whether operations on i128/i256 and more generally on integer types in LLVM are guaranteed to be constant time or not. For instance, for now, the x86 & aarch64 backend generate constant time code for additions on i256 integers (see https://godbolt.org/z/xMfkqz & https://godbolt.org/z/jbkSpe), but is there

On 10 Nov., 15:10, me22 <me22... at gmail.com> wrote: > 2009/11/9 Kenneth Uildriks <kenneth... at gmail.com>: > > > > > 1. Conversions to/from other integer types: right now, integer type > > conversions are always explicity specified as either a trunc, a sext, > > or a zext.  Since the size of intp is not known at IR generation time, > > you

Hi, > First, I guess that smaller integer sizes, say, i1 (boolean) are > stuffed into a full word size for the cpu it is compiled on (so 8bits, > or 32 bits or whatever). on x86-32, an i1 gets placed in an 8 bit register. > What if someone made an i4 and compiled it on 32/64 bit > windows/nix/bsd on a standard x86 or x64 system, and they set the > value to 15 (the max size of

On Mon, Sep 8, 2008 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: > FYI, there is one other issue here, PR2660. While codegen in > general can handle types like i256, individual targets don't always > have calling convention rules to cover them. For example, returning > an i128 on x86-32 or an i256 on x86-64 doesn't doesn't fit in the > registers designated

>However, there is one issue I have ignored - possibility of overflow in >the index expression. Suppose, we have such a loop: > for (i8 i = 0; i != 200; ++i) { > A[2 * i + 5] = ... > ... = A[2 * i + 3] > } >If both index expressions are evaluated in 8-bit arithmetic, >then the dependence equation should be solved in modular arithmetic: > 2 * i + 5 == 2 * (i +

2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>: > > 1. Conversions to/from other integer types: right now, integer type > conversions are always explicity specified as either a trunc, a sext, > or a zext.  Since the size of intp is not known at IR generation time, > you can't know whether a conversion to/from intp truncates or extends. > Now that there are

On Aug 10, 2013, at 2:58 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 9 Aug 2013, at 22:15, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> I am a bit skeptical about the need for pointer types; I don’t think it is the right level of abstraction for an instruction selector. The processors I know about with separate address and data registers

In the general case, I think you have to be conservative about this because programmers may deliberately want this kind of "wraparound" behavior, e.g., with periodic boundary conditions. But 99.9% of programs probably don't need that so it would be bad to penalize them for this corner case. In such a situation, I think you just have to support both choices, but choose the