Hello,
I was inspired by the Quest tool and decided to give it a try on LLVM.
It quickly located two bugs which appear to be in the bug database already:
Bug #279 - [llvmgcc] "constructor" code generation can be improved
Although, the code that Quest generates actually *crashes* LLVM instead
of producing poor output. Should this be added as a separate bug, or just
annotate the existing one?
Bug #323 [llvm-gcc] crashes on union with bitfield
This one pops up quickly when -O3 is turned on. Nothing new compared to
the existing bug.
Since Quest hit these two bugs so frequently, I had to re-arrange the
test generation suite to work around them. Attached is the new ANSI test
suite; simplified to remove floats, doubles, long longs, bitfields, and
includes a work-around for the constructor bug.
Also attached is the auto-test script that I've been running. It's
been
running for 24 hours with no problems (about 200,000 test cases).
Hope this is useful for someone,
--Bryan
bryan.turner at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050608/91703787/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ansifloat.lua
Type: application/octet-stream
Size: 3453 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050608/91703787/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testLLVM
Type: application/octet-stream
Size: 272 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050608/91703787/attachment-0001.obj>
On Wed, 2005-06-08 at 11:22 -0400, Bryan Turner wrote:> Hello, > > I was inspired by the Quest tool and decided to give it a try on > LLVM.Excellent!> It quickly located two bugs which appear to be in the bug database > already: > > Bug #279 - [llvmgcc] "constructor" code generation can be improved > > Although, the code that Quest generates actually *crashes* LLVM > instead of producing poor output. Should this be added as a separate > bug, or just annotate the existing one?Yes, if it crashes, that is much more serious. Please do file a new bug, with the offending source (or even the bugpoint reduced source if you are so inclined). Andrew
Hello (again), I was perusing the nightly tests and looking at the code performance ratios, etc. The worst case I saw was the C++ Shootout benchmark for lists. After some disentangling of the nightly test scripts, I ran the llc version through valgrind to see where the performance bottleneck is, but the results don't include debugger symbols, and the output is useless. I tried using -g on all the tools which accepted it (llvm-gcc, and gcc), but still no luck. I also tried --gstabs on 'as' in place of gcc for the assembly step. It generates errors along the lines of "debugger symbol table too large, use different format". Any idea how I can get debugger symbols into the llc-generated version of the lists benchmark? Did I miss something obvious? Alternatively, does anyone have a better idea to track down why the lists test is drastically worse than the gcc and cbe version? (the assembler file is a bit too large to browse directly without some direction) Thanks, --Bryan bryan.turner at pobox.com
Hi Bryan, (everyone) Thanks for the testing with Quest! I'm wondering, though: does anyone have a random LLVM code generator? It may be helpful in finding bugs that _aren't_ in the C front-end, but it would also be useful to benchmark LLVM - e.g. the JIT generally, register allocators, memory usage etc. One could also measure target code quality I suppose. Well, if not, I might poke around and see what I can come up with. Suggestions/feature-requests welcome! Duraid