llvm dev - Jan 2010 - [LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode

Hi!

We are compiling a very large C project in llvm and trying to execute
it in interpreter. There is a problem with executing the generated
bitcode.

We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release.

We have localized the problem to following c code:
--------------------
int f(unsigned char x) __attribute__((noinline));

int f(unsigned char x)
{
  return x - 1;
}

int main()
{
   return f(1);
}
--------------------


Which generates following llvm assembly:
----------
; ModuleID = 'a.o'
target datalayout
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-mingw32"

define i32 @f(i8 zeroext %x) nounwind readnone noinline {
entry:
  %0 = zext i8 %x to i32                          ; <i32> [#uses=1]
  %1 = add i32 %0, -1                             ; <i32> [#uses=1]
  ret i32 %1
}

define i32 @main() nounwind readnone {
entry:
  %0 = tail call i32 @f(i8 zeroext 1) nounwind    ; <i32> [#uses=1]
  ret i32 %0
}
-----------


Finally calling it with:
----------
llvm-gcc -c -emit-llvm -O2 a.c
lli -force-interpreter a.o
----------

Yields us:
-----------
"Assertion failed: width > BitWidth && "Invalid APInt
ZeroExtend
request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064"
-----------
where both width and BitWidth have value "32".


Removing this assert in llvm source makes more similar (APInt related)
asserts fail later.

Is that a problem with llvm-gcc or is there a fix in llvm source available?


Thank you and we hope to hear from you soon.

Kristaps Straupe wrote:
> Hi!
>
> We are compiling a very large C project in llvm and trying to execute
> it in interpreter. There is a problem with executing the generated
> bitcode.
The interpreter is under-maintained in general, but this bug in 
particular is fixed SVN as-of r86428. Are you on a platform that isn't 
supported by llvm's jit?

Nick
> We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release.
>
> We have localized the problem to following c code:
> --------------------
> int f(unsigned char x) __attribute__((noinline));
>
> int f(unsigned char x)
> {
>    return x - 1;
> }
>
> int main()
> {
>     return f(1);
> }
> --------------------
>
>
> Which generates following llvm assembly:
> ----------
> ; ModuleID = 'a.o'
> target datalayout >
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i386-mingw32"
>
> define i32 @f(i8 zeroext %x) nounwind readnone noinline {
> entry:
>    %0 = zext i8 %x to i32                          ;<i32>  [#uses=1]
>    %1 = add i32 %0, -1                             ;<i32>  [#uses=1]
>    ret i32 %1
> }
>
> define i32 @main() nounwind readnone {
> entry:
>    %0 = tail call i32 @f(i8 zeroext 1) nounwind    ;<i32>  [#uses=1]
>    ret i32 %0
> }
> -----------
>
>
> Finally calling it with:
> ----------
> llvm-gcc -c -emit-llvm -O2 a.c
> lli -force-interpreter a.o
> ----------
>
> Yields us:
> -----------
> "Assertion failed: width>  BitWidth&&  "Invalid APInt
ZeroExtend
> request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064"
> -----------
> where both width and BitWidth have value "32".
>
>
> Removing this assert in llvm source makes more similar (APInt related)
> asserts fail later.
>
> Is that a problem with llvm-gcc or is there a fix in llvm source available?
>
>
> Thank you and we hope to hear from you soon.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Kristaps,
> Finally calling it with:
> ----------
> llvm-gcc -c -emit-llvm -O2 a.c
> lli -force-interpreter a.o
> ----------
> 
> Yields us:
> -----------
> "Assertion failed: width > BitWidth && "Invalid APInt
ZeroExtend
> request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line 1064"
> -----------
> where both width and BitWidth have value "32".
I can't reproduce this with LLVM from subversion, so presumably it
has been fixed.

Ciao,

Duncan.

Hello again!

We have fetched the latest llvm sources from repository and the
original problem has went away. Though now we are facing a new problem
with interpreter on the following c code:

--------------
#include <stdarg.h>
#include <stdio.h>

void doTheThing(int dummy, ...)
{
  va_list ap;
  int z;

  va_start(ap, dummy);
  while( (z = va_arg(ap, int))!=0)
  {
    printf("== %i ==\n", z);
  }
  va_end(ap);
}

int main()
{
  doTheThing(-1, 1, 2, 3, 0);
}
--------------

Running the bitcode of this example through interpreter yields
abnormal result (or even crash if we are very unlucky), whereas on jit
it is working fine.
We are using interpreter because our code is crashing on jit too and
when using the interpreter it is much easier to iron out the problems.
Although as it seems at the current state the interpreter is quite
unreliable.

Thank you,
Kristaps.


On Thu, Jan 28, 2010 at 8:04 PM, Nick Lewycky <nicholas at mxc.ca>
wrote:
> Kristaps Straupe wrote:
>>
>> Hi!
>>
>> We are compiling a very large C project in llvm and trying to execute
>> it in interpreter. There is a problem with executing the generated
>> bitcode.
>
> The interpreter is under-maintained in general, but this bug in particular
> is fixed SVN as-of r86428. Are you on a platform that isn't supported
by
> llvm's jit?
>
> Nick
>
>> We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release.
>>
>> We have localized the problem to following c code:
>> --------------------
>> int f(unsigned char x) __attribute__((noinline));
>>
>> int f(unsigned char x)
>> {
>>   return x - 1;
>> }
>>
>> int main()
>> {
>>    return f(1);
>> }
>> --------------------
>>
>>
>> Which generates following llvm assembly:
>> ----------
>> ; ModuleID = 'a.o'
>> target datalayout >>
>>
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
>> target triple = "i386-mingw32"
>>
>> define i32 @f(i8 zeroext %x) nounwind readnone noinline {
>> entry:
>>   %0 = zext i8 %x to i32                          ;<i32>
 [#uses=1]
>>   %1 = add i32 %0, -1                             ;<i32>
 [#uses=1]
>>   ret i32 %1
>> }
>>
>> define i32 @main() nounwind readnone {
>> entry:
>>   %0 = tail call i32 @f(i8 zeroext 1) nounwind    ;<i32>
 [#uses=1]
>>   ret i32 %0
>> }
>> -----------
>>
>>
>> Finally calling it with:
>> ----------
>> llvm-gcc -c -emit-llvm -O2 a.c
>> lli -force-interpreter a.o
>> ----------
>>
>> Yields us:
>> -----------
>> "Assertion failed: width>  BitWidth&&  "Invalid
APInt ZeroExtend
>> request", file c:/proj/llvm/src/lib/Support/APInt.cpp, line
1064"
>> -----------
>> where both width and BitWidth have value "32".
>>
>>
>> Removing this assert in llvm source makes more similar (APInt related)
>> asserts fail later.
>>
>> Is that a problem with llvm-gcc or is there a fix in llvm source
>> available?
>>
>>
>> Thank you and we hope to hear from you soon.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>