llvm dev - Jul 2009 - [LLVMdev] Running all the backends over test/CodeGen/Generic

Inspired by the dicussion of removing IA64, I just tried running llc
over test/CodeGen/Generic targeting all the legal values of -march and
counting the number of crashes and aborts, as an attempt to roughly
measure the maturity/bitrottedness of the backends.  I went through
and fixed some easy legalization issues; the following is the
remaining issues:

x86-64: 3.  I'm not entirely sure what's going on here, since the
buildbot should be running this.  The assertion is the following:
llc: /home/eli/llvm/lib/Target/TargetRegisterInfo.cpp:59: virtual
const llvm::TargetRegisterClass*
llvm::TargetRegisterInfo::getPhysicalRegisterRegClass(unsigned int,
llvm::MVT) const: Assertion `BestRC && "Couldn't find the
register
class"' failed.

x86-32: 0.

Sparc: 6.  Caused by Sparc overriding LowerArguments instead of using
the normal lowering for arguments, leading to bad interactions with
illegal types.

PPC64: 0.

PPC32: 0.

Alpha: 4.  Two failures are heavily intertwined with Alpha overriding
LowerCallTo rather than using the normal lowering for calls, leading
to bad interactions with illegal types. One failure relating to inline
asm, and one failure involving ISD::FPOWI where I'm not entirely sure
what's supposed to happen.

IA64: 56. One big issue is the following assertion:
lib/Target/ELFTargetAsmInfo.cpp:175: const llvm::Section*
llvm::ELFTargetAsmInfo::MergeableStringSection(const
llvm::GlobalVariable*) const: Assertion `getCStringSection() &&
"Should have string section prefix"' failed.  Another major issue
is
that IA64 has an f64 register type, but not an f32 register type, and
type legalization goes completely screwy trying to legalize the f32
values.  Another issue is that the IA64 backend overrides
LowerArguments and LowerCallTo instead of using the normal lowering
for calls, leading to bad interactions with illegal types.  Another
issue is that various floating-point comparison operators are
unimplemented.  The issue that takes the cake, though, is that
lowering for the malloc instruction and memcpy intrinsic is broken!

Thumb: 2.  Both failures print "Unsupported addressing mode!"

Arm: 0.

Mipsel/mips: 20.  Goes down to 8 using a triple containing
mipsallegrex, which uses soft-float expansion for doubles.  The 8 are
a bunch of inline asm failures and a couple of "Return operand #2 has
unhandled type i32" failures.  The other crashes are related to issues
with support for hard-float doubles.

CellSPU: 29.  Suffers from misc unimplemented operations; the most
common issues appear to be 128-bit shifts, functions returning i8, and
a strange error "SPU SelectAFormAddr: Constant/Pool/Global not
lowered.".
PIC16/Cooper: 46.  A lot of them probably don't really matter, though,
because this backend isn't really designed to run general code.

XCore: 6 failures, all related to inline asm

MSP430: 18 failures.  Misc issues.

SystemZ: 18 failures.  Misc issues.


Overall, having done this, I'm not sure it says anything useful except
that the IA64 is in fact very broken and that we have bugs we should
fix :)

Note that I used the following bash one-liner to run these tests:
let x=0; echo > /tmp/tests.txt; for file in *.ll; do echo $file >>
/tmp/tests.txt; llvm-as < $file | llc -march=systemz > /dev/null 2>>
/tmp/tests.txt; if [ $? -ne 0 ]; then let x++; fi; done; echo $x

-Eli