Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SparcV9] The SparcV9 backend miscompiles several programs #432

Closed
llvmbot opened this issue Oct 27, 2003 · 18 comments
Closed

[SparcV9] The SparcV9 backend miscompiles several programs #432

llvmbot opened this issue Oct 27, 2003 · 18 comments
Labels

Comments

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Oct 27, 2003

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
Copy link
Collaborator

@lattner lattner commented Feb 10, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Feb 24, 2004

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

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Feb 24, 2004

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

@lattner
Copy link
Collaborator

@lattner lattner commented Feb 25, 2004

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
Copy link
Collaborator

@lattner lattner commented Feb 25, 2004

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

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Feb 26, 2004

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
Copy link
Collaborator

@lattner lattner commented Feb 26, 2004

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

1 similar comment
@lattner
Copy link
Collaborator

@lattner lattner commented Feb 26, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Apr 5, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Apr 5, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Apr 9, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Jun 29, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Jun 29, 2004

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
Copy link
Collaborator

@lattner lattner commented Aug 17, 2004

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
Copy link
Collaborator Author

@llvmbot llvmbot commented Aug 18, 2004

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.

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Aug 22, 2004

SparcV9 llc fails an assertion on the following test case. It's a stupid
program, but all the other code generators can handle it.


implementation ; Functions:

void %main() {
entry:
call void null( )
ret void
}

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Aug 23, 2004

This test case produces bad assembly code (rejected by solaris as):


target endian = big
target pointersize = 64
%struct..TorRec = type { int, void ()* }
%llvm.global_ctors = internal constant [2 x %struct..TorRec] [ %struct..TorRec { int 65535, void ()* %ctor
}, %struct..TorRec { int 2147483647, void ()* null } ] ; <[2 x %struct..TorRec]> [#uses=2]
%llvm.global_dtors = internal constant [2 x %struct..TorRec] [ %struct..TorRec { int 65535, void ()
%dtor
}, %struct..TorRec { int 2147483647, void ()* null } ] ; <[2 x %struct..TorRec]*> [#uses=2]

implementation ; Functions:

internal void %ctor() {
entry:
ret void
}

internal void %dtor() {
entry:
ret void
}

I think it's due to the recent sparcv9 assembly writer changes. The assembly writer is emitting zero
bytes in the global_ctors and global_dtors arrays using .xword, at a point at which the current location
in the assembly file is not 64-bit aligned. I haven't completely analyzed this yet. It affects many large
(MultiSource and SPEC) programs.

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Sep 13, 2004

Comment#16 and comment#17 are now out of date.
Here is a partial list of failing SPEC benchmarks as of 10-Sep-2004.

CFP2000/177.mesa

An assertion fails trying to generate assembly code with llc:

/home/vadve/gaeke/llvm_seraph/tools/Debug/llc -f Output/177.mesa.llvm.bc -o Output/
177.mesa.llc.s
Assertion failed: UserRegType == RegTypeWanted && "Default method is probably incorrect for class
with multiple types.", file SparcV9RegInfo.h, line 62

CINT2000/175.vpr, CINT2000/253.perlbmk, and CINT2000/252.eon

Branches (using the "brz" opcode) are being emitted too far away from their targets, resulting in
assembler errors of the following form. The specified lines of the llc output file are shown for reference.

/usr/dcs/software/evaluation/bin/gcc Output/175.vpr.llc.s -lm -lm -lm -o Output/175.vpr.llc
/usr/ccs/bin/as: "Output/175.vpr.llc.s", line 47777: error: word displacement will not fit in 16 bits
47777 brz %o0, .L_main_l2_loopexit_2E_3_2E_i
/usr/ccs/bin/as: "Output/175.vpr.llc.s", line 47963: error: word displacement will not fit in 16 bits
47963 brz %o0, .L_main_l2_loopexit_2E_3_2E_i_2E_loopexit
/usr/dcs/software/evaluation/bin/gcc Output/252.eon.llc.s -lm -lstdc++ -lm -o Output/252.eon.llc
/usr/ccs/bin/as: "Output/252.eon.llc.s", line 81541: error: word displacement will not fit in 16 bits
81541 brz %l0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8
/usr/ccs/bin/as: "Output/252.eon.llc.s", line 115522: error: word displacement will not fit in 16 bits
115522 brz %o0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8
/usr/ccs/bin/as: "Output/252.eon.llc.s", line 115533: error: word displacement will not fit in 16 bits
115533 brz %o0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8
[etc.]

CINT2000/176.gcc

A miscompilation is causing the llc-generated code for gcc to crash with a segfault. The stack trace is
as follows:

Core was generated by `../../Output/176.gcc.llc cp-decl.i -o - -quiet'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
#​0 0x100027cb8 in l73_decl_attributes ()
#​0 0x100027cb8 in l73_decl_attributes ()
#​1 0x100067be0 in l101_finish_struct ()
#​2 0x1000a2f68 in l184_yyparse ()
#​3 0x100370710 in l177__2E_compile_file_28 ()
#​4 0x100387f5c in main ()

CINT2000/253.perlbmk

The gcc-compiled ("native") benchmark does not work - it crashes with a bus error, and the stack trace
is as follows:

Core was generated by `../../Output/253.perlbmk.native scrabbl.pl'.
Program terminated with signal 10, Bus error.
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
#​0 0x10007f6cc in reganode ()
#​0 0x10007f6cc in reganode ()
#​1 0x10007aed8 in reg ()
#​2 0x10007d2d8 in regatom ()
#​3 0x10007c410 in regpiece ()
#​4 0x10007c2ec in regbranch ()
#​5 0x10007aee8 in reg ()
#​6 0x10007a598 in Perl_pregcomp ()
#​7 0x10002fcb0 in Perl_pmruntime ()
#​8 0x100042bcc in Perl_yyparse ()
#​9 0x100039560 in perl_parse ()
#​10 0x1000b04e0 in main ()

CINT95/126.gcc

An assertion fails trying to generate assembly code with llc:

/home/vadve/gaeke/llvm_seraph/tools/Debug/llc -f Output/126.gcc.llvm.bc -o Output/126.gcc.llc.s
Assertion failed: (!isBranch || AddedInstrMap[MInst].InstrnsAfter.size() <= TM.getInstrInfo()-

getNumDelaySlots(MInst->getOpcode())) && "Cannot put more than #delaySlots instrns after " "branch
or return! Need to handle temps differently.", file PhyRegAlloc.cpp, line 570

CINT95/132.ijpeg

This benchmark doesn't link because it can't find the symbol sys_errlist.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants