similar to: [LLVMdev] i256 for x86_64

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.

Yes I use 2.6 as my OS seems to be too old for 2.7. Are there any restrictions on integer types for x86_64? On Tue, May 25, 2010 at 5:25 PM, Chris Lattner <clattner at apple.com> wrote: > > 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

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

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

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

I've been playing around with LLVM to write a backend for a rather "simple" (co-)processor. Assume that only three arithmetic instructions exist: ADD mod N, SUB mod N and MUL mod N. The modulus N is programmable and stored in a register. No ordinary arithmetic instructions are available. The word size is 256-bit. In other words, the following function, b + c mod N, corresponds to

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

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

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

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

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

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

Have you looked at these? https://llvm.org/docs/LangRef.html https://llvm.org/docs/ExtendingLLVM.html On Tue, Mar 26, 2019 at 9:06 AM div code via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Of course, in this sense they are not platform-dependent. I just want to > write a semantics-correct version of such intrinsics and let my static > analyzer goes smoothly. > > On

Hello, I am basically working on a static analysis project on LLVM IR, and the problem is that I will need to simulate the execution of a few LLVM Intrinsic, such as llvm.bswap.i160, and llvm.ctlz.i256. I am wondering if there has been some already implemented sample code, regarding these intrinsics? Either C or LLVM IR. Thanks a lot! Best, -------------- next part -------------- An HTML

Hi LLVM, 1. Can mul and/or div support be added for big integer types like i256? 2. What are the limits? 3. If yes, how should it be done? I have experience only with X86 target and know that mul i128 works and div i128 is lowered to function call from compile-rt like library (what works only if you link with such library). Can that support be extended? - Paweł -------------- next part

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed...