[SparcV9] The SparcV9 backend miscompiles several programs

[llvmbot]

Bugzilla Link	60
Resolution	WONTFIX
Resolved on	Feb 22, 2010 12:42
Version	1.0
OS	Solaris
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

The 177.mesa test fails on Sparc (seraph). The numerical output does not match
that generated by the native version of 177.mesa.

[lattner]

How does this test fail? Are the numbers close, but slightly different? Or is
it obviously wrong in some major way? I'm seeing mesa fail on X86 with
LARGE_PROBLEM_SIZE, but I think that it's roundoff or similar issues...

-Chris

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#145 has been marked as a duplicate of this bug. ***

[llvmbot]

(Bug 145 notes that the SPARC also apparently fails in the JIT on Mesa.)

[lattner]

I'm just going to make this a general "the sparc backend has issues" bug. Many
spec benchmarks don't work, many multisource benchmarks don't work, and noone is
interested in fixing them.

-Chris

[lattner]

*** Bug llvm/llvm-bugzilla-archive#144 has been marked as a duplicate of this bug. ***

[llvmbot]

It seems that the sparc backend (as of 26-Feb) can't
seem to compile simple programs (e.g. nestedloop.llvm.bc) that come out
of the x86 backend. This is not the usual case, admittedly, but I don't think
that it should cause a crash. It crashes in
InstructionSelection::SelectInstructionsForTree().

[lattner]

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

[lattner]

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

[llvmbot]

The sparcv9 code generator will sometimes generate branches for which the displacement is too large
to fit in the appropriate field of the branch instruction. This bug afflicts 252.eon in llc. It manifests itself
as invalid output from llc - the Solaris assembler fails to assemble the branch instruction(s) in question
and prints an error message.

The sparcv9 code generator will also sometimes let the SETSW pseudo-instruction be seen by the JIT
code emitter. This bug afflicts 252.eon in the JIT. It manifests itself in SparcV9CodeEmitter: it hits the
end of the giant switch statement, prints an error message, and aborts.

[llvmbot]

The following spec2000 programs are also currently known to fail with llvm for sparcv9:

177.mesa llc - fails assertion in TargetRegInfo
177.mesa cbe - fails diffs
177.mesa jit - fails diffs
175.vpr llc - fails diffs (FP problem?)
186.crafty llc - fails assertion in PhyRegAlloc
252.eon llc - output fails to assemble (see above)
252.eon jit - fails assertion in SparcV9CodeEmitter (see above)
253.perlbmk llc - fails diffs
253.perlbmk cbe - fails diffs

[llvmbot]

MallocBench/cfrac does not work on the sparc using the native 64-bit sparc gcc, or
using the LLVM tools configured for sparcv9. It does work using native 32-bit sparc
gcc, which suggests that it is not 64-bit clean.

[llvmbot]

MultiSource/Benchmarks/Olden:
power fails in cbe. This is because Solaris doesn't have the (new in C99) printf
%a format specifier.
voronoi fails in jit (but not llc!). Not quite sure why.

SingleSource/UnitTests:
2003-05-26-Shorts.c appears to fail, but in fact, the LLVM compiler produces
the correct output, and native GCC is wrong.

[llvmbot]

The following SPEC2000 programs are failing on sparcv9. This supersedes the previous list.

175.vpr llc - "word displacement will not fit in 16 bits" error from SPARC as
252.eon llc - "word displacement will not fit in 16 bits" error from SPARC as
253.perlbmk llc - "word displacement will not fit in 16 bits" error from SPARC as

176.gcc cbe,jit - segmentation fault
252.eon jit - segmentation fault
253.perlbmk jit - segmentation fault

176.gcc native,llc - aborts in expand_expr()
177.mesa cbe - fails diffs
177.mesa llc - Assertion failed: UserRegType == RegTypeWanted && "Default method is probably
incorrect for class with multiple types.", file SparcV9RegInfo.h, line 62
186.crafty native,llc,cbe,jit - cpu time limit exceeded (time limit = 2000)
252.eon native - can't find output files pixels_out.kajiya, pixels_out.rushmeier?
253.perlbmk native,cbe - bus error

[lattner]

This testcase crashes the V9 code generator:

---

implementation ; Functions:

void %Warning(double %level, sbyte* %format, ...) {
entry:
ret void
}

llc: SparcV9RegInfo.cpp:459: void llvm::SparcV9RegInfo::colorMethodArgs(const
llvm::Function*, llvm::LiveRangeInfo&, std::vector<llvm::MachineInstr*,
std::allocatorllvm::MachineInstr* >&, std::vector<llvm::MachineInstr*,
std::allocatorllvm::MachineInstr* >&) const: Assertion `0 && "This could
should work but it is not tested yet"' failed.

-Chris

[llvmbot]

This is what you get when you run bugpoint after taking out the "This should work"
assertion. It's a very slightly expanded version of the previous testcase:

---

implementation ; Functions:

void %Warning(double %level, sbyte* %format, ...) {
entry:
%tmp.7 = setgt double 0x0, %level ; [#uses=0]
ret void
}

The "This should work" assertion failure Chris posted in comment#14 is actually
obscuring another, more serious problem: the sparcv9 register allocator is trying to
allocate %level to an odd-numbered %f-register, which is not OK; on sparcv9,
doubles are supposed to be allocated to (even,odd)-numbered pairs of
(32-bit-wide) %f-registers addressed by the lower, even-numbered register in the
pair. (It's explained in the ABI doc.) I'm not sure how to fix this yet.