similar to: [LLVMdev] Large integers as first-class values

On Sun, Feb 28, 2010 at 11:54 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > So my question is, is it okay to go ahead and do this, or are there > any caveats in terms of efficiency or correctness? In particular, I > remember reading something about there being problems with returning > integers larger than two machine words, but I can't find it again; is >

On Sun, Feb 28, 2010 at 8:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > In terms of correctness, it should work except for the fact that the > LLVM code generators don't implement more complicated operations on > such integers, like multiplication, division, and variable-width > shifts.  The issues with returning large integers are fixed, at least > on x86. But

On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Sun, Feb 28, 2010 at 8:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> In terms of correctness, it should work except for the fact that the >> LLVM code generators don't implement more complicated operations on >> such integers, like multiplication, division,

On Sun, Feb 28, 2010 at 9:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace > <russell.wallace at gmail.com> wrote: >> What's the largest integer such that something like 'return ((a * b) / >> c) >> d' works correctly on all major platforms? > > Twice the size of a pointer, i.e. 64 bits on

On 28 February 2010 16:10, Russell Wallace <russell.wallace at gmail.com> wrote: > > Okay, thanks. Do I understand correctly that this is likely to > continue to be the case, so language support for large integers will > need to be implemented by other means? > Maybe it would be worth adding "iInf" to LLVM to use all the pre-existing optimizations, then have passes

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

On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: > Hi Eli, > > On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote: >>> a) What plans are there to support addition, subtraction, >>> multiplication, division,

On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: > No, C only requires support for objects up to 65535 bytes in size.  C99 5.2.4.1. 65535 bytes would be reasonably sufficient; what's the largest supported by the LLVM code generator?

I was able to get the loop to increment from -999 to 0 using IR directly. That got rid of the cmpq. The carry i was after was able to be obtained using the intrinsic @llvm.uadd.with.overflow.i64, however there is no way to add with carry and have it realise that the resulting *carry out* cannot exceed 1. It actually writes the carry to a byte, and then uses logical operations on it, which slows

On 12 June 2010 00:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: >> Hi Eli, >> >> On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote:

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The

First off, most of my information about the integer representation in LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could use some things cleared up. 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). What if someone made an i4 and compiled it on 32/64 bit windows/nix/bsd

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

On Tue, Mar 2, 2010 at 2:34 AM, Dan Gohman <gohman at apple.com> wrote: > If you're wondering what this limit is, you're probably heading down > the wrong path, unless you're ultimate interest here is to work on > optimizer techniques for transforming this kind of code into > something usable. No, I'm just trying for correctness -- most of the time, only small

On 12 June 2010 00:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: >> Hi Eli, >> >> On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote:

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

Does LLVM support any target platforms on which the natural integer size/pointer size is smaller than 32 bits? For example, I noticed mention of PIC16, is that such a platform? If so, does the usual rule about the largest supported integer being the size of two pointers still apply? So that on that platform you can't use 64-bit integers, but you can use 32-bit integers?

On Mar 1, 2010, at 2:49 PM, Russell Wallace wrote: > On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: >> No, C only requires support for objects up to 65535 bytes in size. C99 5.2.4.1. > > 65535 bytes would be reasonably sufficient; what's the largest > supported by the LLVM code generator? If you're wondering what this limit is,

On Mon, Mar 1, 2010 at 7:39 PM, Reid Kleckner <rnk at mit.edu> wrote: > IIRC they lower it themselves, doing whatever the ABI says they > should, which is usually adding a hidden sret parameter to the > function once you get beyond small structs. Okay, so we seem to be saying sret or suchlike is how you pass and return large objects by value in LLVM. What exactly counts as large?

Well yes, LLVM is Turing complete :-) but I take your point, one could in a pinch hack the same functionality in the front-end. Would that likely be easier or harder than doing it properly in the code generator? Other things equal, of course the latter would be preferable. How do LLVM-GCC and Clang handle it? On Mon, Mar 1, 2010 at 3:36 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi