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@pobox.com
ansifloat.lua (3.37 KB)
testLLVM (272 Bytes)
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@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