On Tue, 20 Jun 2006, Chris Lattner wrote:> On Wed, 21 Jun 2006, Simon Burton wrote: >> This from the output: >> >> 24620 x86-emitter - Number of machine instructions emitted >> >> (i had to write a dummy main function to get this to work) >> >> Is this really the number of bytes of machine code ? > Yes.To be specific, this is the number of bytes of machine code JIT'd. Thus, this only includes the stuff reachable from main, for example. To see specifically what functions it is compiling and how big they are, use: lli -debug-only=jit foo.bc <args> -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Tue, 20 Jun 2006 22:38:24 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote:> > >> Is this really the number of bytes of machine code ? > > Yes. > > To be specific, this is the number of bytes of machine code JIT'd. Thus, > this only includes the stuff reachable from main, for example. To see > specifically what functions it is compiling and how big they are, use: > > lli -debug-only=jit foo.bc <args>This does not seem to be available in my build (1.7 release-asserts). Another question: does lli actually run the program ? I've cooked up a main function that would probably segfault it. And what i'm seeing (with strace) is that something does segfault (a child thread?) and lli is waiting on a futex: access("dump.bc", F_OK) = 0 open("dump.bc", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=22744, ...}) = 0 mmap2(NULL, 24576, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe3000 mmap2(NULL, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d9c000 mmap2(0xb7d9c000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6c9c000 mmap2(0xb6d9c000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6b9c000 futex(0xb7fbb1b4, FUTEX_WAKE, 2147483647) = 0 brk(0) = 0x8562000 brk(0x8583000) = 0x8583000 brk(0) = 0x8583000 brk(0x85a4000) = 0x85a4000 brk(0) = 0x85a4000 brk(0x85c5000) = 0x85c5000 brk(0) = 0x85c5000 brk(0x85e6000) = 0x85e6000 brk(0) = 0x85e6000 brk(0x8609000) = 0x8609000 brk(0) = 0x8609000 brk(0x862b000) = 0x862b000 brk(0) = 0x862b000 brk(0x864c000) = 0x864c000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- pipe([4, 5]) = 0 futex(0xb7ecf900, FUTEX_WAIT, 2, NULL <unfinished ...> dump.bc attached. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com -------------- next part -------------- A non-text attachment was scrubbed... Name: dump.bc Type: application/octet-stream Size: 22744 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060621/bd4b9001/attachment.obj>
On Wed, 21 Jun 2006, Simon Burton wrote:>> To be specific, this is the number of bytes of machine code JIT'd. Thus, >> this only includes the stuff reachable from main, for example. To see >> specifically what functions it is compiling and how big they are, use: >> >> lli -debug-only=jit foo.bc <args> > > This does not seem to be available in my build (1.7 release-asserts).Right, release-asserts builds have no debug stuff in them.> Another question: does lli actually run the program ?Yup.> I've cooked up a main function that would probably segfault it. > And what i'm seeing (with strace) is that something does segfault (a child thread?) and > lli is waiting on a futex:Right. lli is the JIT, which dynamically compiles code as it goes. If you're just curious about code size, why not use size on .o file? -Chris> access("dump.bc", F_OK) = 0 > open("dump.bc", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0600, st_size=22744, ...}) = 0 > mmap2(NULL, 24576, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe3000 > mmap2(NULL, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d9c000 > mmap2(0xb7d9c000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6c9c000 > mmap2(0xb6d9c000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6b9c000 > futex(0xb7fbb1b4, FUTEX_WAKE, 2147483647) = 0 > brk(0) = 0x8562000 > brk(0x8583000) = 0x8583000 > brk(0) = 0x8583000 > brk(0x85a4000) = 0x85a4000 > brk(0) = 0x85a4000 > brk(0x85c5000) = 0x85c5000 > brk(0) = 0x85c5000 > brk(0x85e6000) = 0x85e6000 > brk(0) = 0x85e6000 > brk(0x8609000) = 0x8609000 > brk(0) = 0x8609000 > brk(0x862b000) = 0x862b000 > brk(0) = 0x862b000 > brk(0x864c000) = 0x864c000 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > pipe([4, 5]) = 0 > futex(0xb7ecf900, FUTEX_WAIT, 2, NULL > <unfinished ...> > > dump.bc attached. > > Simon. > >-Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wed, 21 Jun 2006 14:17:07 +1000 Simon Burton <simon at arrowtheory.com> wrote:> > Another question: does lli actually run the program ? > I've cooked up a main function that would probably segfault it.I think i've fixed this now. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com