llvm dev - Sep 2008 - [LLVMdev] Integer questions

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

> 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.
Was looking through some other code in LLVM, I noticed an abort(), how
often do those occur as they would be *really* bad to occur in my
circumstances (the couple I saw were in the JIT class) as catching the
abort signal may not always be possible depending on the hosts code.

Will the verifier catch things like integers that are too big for the
platform that I am currently on, or will that be done by something
like the JIT when it compiles it?

And yea, assertions are a very large "no" in this library, especially
since bad code will probably happen very often (it is effectively a
scripting language, will load, compile, and run code at run time, I do
expect to write out things to a cache to help future loading time
though, time is not really an issue during loading, but there may be a
potentially massive amount of code later on, so better safe then
sorry, not to mention that code speed during execution needs to be as
fast as possible, the normal scripting languages out are no where near
fast enough according to tests, at least the ones that are capable of
continuations)

Which brings me to something else, I will create a new thread due to
the massive topic change...

On Sep 8, 2008, at 4:30 PM, OvermindDL1 wrote:
>> 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.
>
> Was looking through some other code in LLVM, I noticed an abort(), how
> often do those occur as they would be *really* bad to occur in my
> circumstances (the couple I saw were in the JIT class) as catching the
> abort signal may not always be possible depending on the hosts code.
>
> Will the verifier catch things like integers that are too big for the
> platform that I am currently on, or will that be done by something
> like the JIT when it compiles it?
No, the verifier currently does not know about target-specific
codegen limitations.

>
> And yea, assertions are a very large "no" in this library,
especially
> since bad code will probably happen very often
Patches to do the kind of checking you're asking about would be
welcome :-). I don't think it makes sense to extend the
Verifier itself here; it's supposed to accept any valid LLVM IR.
I think a separate CodeGenVerifier might be a good approach
though, or possibly extending codegen itself with the ability to
interrupt itself and yield some kind of error status.

Dan