Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] new at LLVM"
2009 Oct 31
3
[LLVMdev] Something wrong with my libpthread.so
Hi,all
I tried to run the generated whole-program bitcode of BIND,but I got some
information:
0 lli 0x0000000000feda16
1 lli 0x0000000000fed88f
2 libpthread.so.0 0x0000003df340eee0
3 libc.so.6 0x0000003df28332f5 gsignal + 53
4 libc.so.6 0x0000003df2834b20 abort + 384
5 libc.so.6 0x0000003df282c2fa __assert_fail + 234
6 lli
2009 Nov 01
0
[LLVMdev] Something wrong with my libpthread.so
Hi,
On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote:
> Hi,all
>
> I tried to run the generated whole-program bitcode of BIND,but I got some
> information:
>
> 0 lli 0x0000000000feda16
> 1 lli 0x0000000000fed88f
> 2 libpthread.so.0 0x0000003df340eee0
> 3 libc.so.6 0x0000003df28332f5 gsignal + 53
>
2009 Nov 01
1
[LLVMdev] Something wrong with my libpthread.so
Mahadevan R wrote:
> Hi,
>
> On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote:
>> Hi,all
>>
>> I tried to run the generated whole-program bitcode of BIND,but I got some
>> information:
>>
>> 0 lli 0x0000000000feda16
>> 1 lli 0x0000000000fed88f
>> 2 libpthread.so.0
2009 Nov 15
0
[LLVMdev] Very slow performance of lli on x86
Sorry i really forgot to mention one thing. I downloaded the X86 binaries of
llvm+clang and llvm-gcc from llvm download site. i hope that is not a debug
build.
Prasanth J
On Sun, Nov 15, 2009 at 1:22 PM, Prasanth J <j.prasanth.j at gmail.com> wrote:
> Hi all,
>
> LLVM is built without debug enabled. Also i am not forcing lli to use
> interpreter mode. so i dont think the
2009 Nov 15
5
[LLVMdev] Very slow performance of lli on x86
Hi all,
LLVM is built without debug enabled. Also i am not forcing lli to use
interpreter mode. so i dont think the reason is not because of debug build
or interpreter mode.
*step 1: *
compiled the 3 files (generic_replica.c ,xacc.c and dacc.c) with clang-cc to
llvm bytecode files using -emit-llvm-bc and (-O0/-O3) options
*step 2:*
bytecode obtained from step 1 (generic_replica.bc, xacc.bc and
2009 Nov 14
0
[LLVMdev] Very slow performance of lli on x86
He is probably using the interpreter on a debug build.
Evan
On Nov 14, 2009, at 1:40 PM, Eric Christopher <echristo at apple.com>
wrote:
>>
>> for -O3 results refer attachment.
>> time clang (-
>> O0) llvm-gcc(-O0)
>> gcc(-O0)
>> real
>> 0m10.247s
2012 Feb 06
0
[LLVMdev] misc questions on opt and bitcode
Works for me:
[jhereg:~/tmp] echristo% /Volumes/Data/builds/build-llvm/Debug+Asserts/bin/clang -S -emit-llvm foo.cpp
[jhereg:~/tmp] echristo% lli foo.s
testing
[jhereg:~/tmp] echristo% llvm-gcc -S -emit-llvm foo.cpp
[jhereg:~/tmp] echristo% lli foo.s
testing
the first is using top of tree clang. The second is using an llvm-gcc on my OS. What versions are you using?
-eric
On Feb 6, 2012, at
2012 Feb 06
2
[LLVMdev] misc questions on opt and bitcode
Hi Eric,
Here's the C code (example.c):
include <stdio.h>
int main()
{
printf("testing\n");
}
Here's the LLVM IR (from llvm-gcc):
ModuleID = 'example.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple =
2009 Nov 14
2
[LLVMdev] Very slow performance of lli on x86
>
> for -O3 results refer attachment.
> time clang (-O0) llvm-gcc(-O0) gcc(-O0)
> real 0m10.247s 0m11.324s 0m10.963s
> user 0m2.644s 0m2.478s 0m2.263s
2020 Feb 01
0
Interpreter crash due to an "Unknown constant pointer type!"
Hi Alberto,
Can you please file a bug for it, with the test case attached (if you
haven't already).
Thanks,
Ehud.
On Sat, 1 Feb 2020 at 11:32 Alberto Barbaro via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
> just a gentle reminder :) Is there any update on this please?
>
> Happy to help in any way I can
>
> Alberto
>
> Il giorno ven 3 gen 2020 alle
2009 Nov 16
1
[LLVMdev] Very slow performance of lli on x86
Hi all,
I have attached the complete test suite. it has different directories for
gcc, llvm-gcc , clang and lli-clang. Source code , makefile and run script
(contains number of times the program should execute) for each case are
available inside each directory.
*
FOLLOWING ARE THE STATISTICS WHILE USING LLI FOR SINGLE ITERATION*
2009 Nov 18
0
[LLVMdev] lli -force-interpreter complains about external function
Hi Nick:
The first problem have been solved by calling llvm-ld:
$ llvm-ld -o hellosin.llvm hellosin.bc -lm
$ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc
hello sin: 0.50
The pthread problem remains after llvm-ld:
$ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc
0 lli 0x08796bf8
Segmentation fault
For those who are getting "invalid
2009 Nov 18
0
[LLVMdev] lli -force-interpreter complains about external function
Hi Nick:
Thanks for the response.
You are right about sinf.
I changed the constant to sscanf(argv[1], ...), and it gave me back 0 again.
I also compared the disassembled code, and saw it was indeed the case.
The primary reason I use interpreter is because I wish to do runtime
checking on memory access pattern in multithreaded C programs. for example,
if thread one is in the critical section, I
2013 Aug 02
0
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
Milind,
Have you filed a bug on this? If not, can you please open a bug report (http://llvm.org/bugs)?
-Hal
----- Original Message -----
> I am hitting an LLVM assertion from the llc tool iff the bitcode file
> is optimized at -O3 level by opt). -O1 and -O2 levels of opt do not
> cause this assert.
>
> LLVM version 3.4svn
> DEBUG build with assertions.
> Built Jul 14
2020 Feb 10
2
Interpreter crash due to an "Unknown constant pointer type!"
>
> Hey Lang - does any of this look familiar to you?
I'm afraid not: I know nothing about the interpreter. As far as I'm aware
it's essentially abandonware.
Alberto: The usual recommendation in these circumstances is to use a JIT
class instead of the interpreter. You're using -force-interpreter though,
so I assume you really want to use the interpreter for your use case?
2013 Jan 26
1
[LLVMdev] MCJIT/interpreter and iostream
As of LLVM 3.2, is it possible to use iostream with the MCJIT or interpreter execution engines? I'm getting some errors...
Each of these commands correctly prints "hello":
echo -e '#include <stdio.h>\nint main(){ printf("hello"); }' | clang -cc1 -emit-llvm-bc -x c++ | lli -use-mcjit
echo -e '#include <iostream>\nint main(){ std::cout <<
2013 Jul 29
2
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
I am hitting an LLVM assertion from the llc tool iff the bitcode file
is optimized at -O3 level by opt). -O1 and -O2 levels of opt do not
cause this assert.
LLVM version 3.4svn
DEBUG build with assertions.
Built Jul 14 2013 (15:39:08).
Default target: x86_64-unknown-linux-gnu
Host CPU: amdfam10
I have attached the input bc file before -O3 optimization :bzip2.del.bc.tgz
I have attached
2019 Dec 19
2
Interpreter crash due to an "Unknown constant pointer type!"
Hi David,
Thanks for the suggestions. I can definitely provide the example bc file
and image ( please see the attachments ). For the debug + asserts I need a
bit of more time.
Anyway the full output of lli is:
lli --force-interpreter examples/pngpixel_crash.bc 0 0 examples/mini.png
png_ptr->width: 1
max_pixel_depth: 24
row_bytes: 28
Unknown constant pointer type!
UNREACHABLE executed at
2009 Nov 18
3
[LLVMdev] lli -force-interpreter complains about external function
Xu Yang wrote:
> Hi Nick:
>
> The first problem have been solved by calling llvm-ld:
>
> $ llvm-ld -o hellosin.llvm hellosin.bc -lm
> $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc
> hello sin: 0.50
Only because the optimizer saw sin(constant) and folded it away. The
entire program became 'print constant string'. There is certainly a bug
2013 Aug 09
0
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
Hi,
I don't see the LLVM bug I filed
(http://llvm.org/bugs/show_bug.cgi?id=16780) making any progress.
Can someone suggest me whether the bug is in the correct state?
-Milind
On Fri, Aug 2, 2013 at 1:29 PM, Milind Chabbi <Milind.Chabbi at rice.edu> wrote:
> Hi Hal,
>
> I have filed http://llvm.org/bugs/show_bug.cgi?id=16780
>
> -Milind
>
> On Fri, Aug 2, 2013 at