llvm dev - Sep 2008 - [LLVMdev] Integer questions

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 those targets.
I am mostly just interested in x86 (32-bit and 64-bit) based systems,
so it would choke?  And how would it choke (exception thrown, some
getlasterror style message passing, or what?).  To ask bluntly, I
would need to do bignum arithmetic in my side, rather then letting
LLVM do it (since the backend would most likely not do it)?

Has anyone thought about putting bignum's inside LLVM itself, LLVM
would be able to generate the best things possible for a given system,
and I do not mean bignum like some arbitrary sized number ala
Python/Erlang/etc. number, some static sized integer would be best for
my use, i2048 for example, although if there were an arbitrary length
version I would put that in the language as well.

Which I guess I should also ask about, how does LLVM do error handling
for when something cannot be compiled for whatever reason?

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 returning values on those targets.
>
> I am mostly just interested in x86 (32-bit and 64-bit) based systems,
> so it would choke?  And how would it choke (exception thrown, some
> getlasterror style message passing, or what?).  To ask bluntly, I
> would need to do bignum arithmetic in my side, rather then letting
> LLVM do it (since the backend would most likely not do it)?
If assertions are enabled, it will trigger an assertion failure.
This particular issue is only relevant for function return values.
>
>
> Has anyone thought about putting bignum's inside LLVM itself, LLVM
> would be able to generate the best things possible for a given system,
> and I do not mean bignum like some arbitrary sized number ala
> Python/Erlang/etc. number, some static sized integer would be best for
> my use, i2048 for example, although if there were an arbitrary length
> version I would put that in the language as well.
Integers like i2048 that are well beyond the reach of the register
set on x86 pose additional challenges if you want efficient generated
code.
>
>
> Which I guess I should also ask about, how does LLVM do error handling
> for when something cannot be compiled for whatever reason?
The Verifier pass is recommended; it catches a lot of
invalid stuff and be configured to abort, print an error to
stderr, or return an error status and message string.

It doesn't catch everything though; codegen's error
handling today is usually an assertion failure, assuming
assertions are enabled.

Dan