search for: pr2660

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 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 for returning values on those targets. Dan

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 for returning values on th...

Hi all, Are there any plans of supporting large aggregate types for function return types in the near future? 2.6? Thanks & Regards, -Mahadevan.

On Apr 23, 2009, at 8:09 PM, Dan Gohman wrote: > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major > change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary

On Sep 8, 2008, at 1:39 PM, OvermindDL1 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 for return...

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

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

Hello, Attached is a patch which significantly reworks how calls, incoming arguments, and outgoing return values are lowered. It's a major change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work.