[LLVMdev] Integer questions

Dan Gohman gohman at apple.com
Mon Sep 8 14:32:13 PDT 2008


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




More information about the llvm-dev mailing list