llvm-test/MultiSource/Benchmarks/Olden/health fails on x86-64

[edwintorok]

Bugzilla Link	2197
Resolution	FIXED
Resolved on	Sep 08, 2008 10:45
Version	unspecified
OS	Linux
Attachments	report file, bugpoint.safe.bc, bugpoint.test.bc
CC	@asl,@sunfishcode

Extended Description

On SVN r49248, x86-64 Linux:

---

========= '/MultiSource/Benchmarks/Olden/health/health' Program

---

TEST-PASS: compile /MultiSource/Benchmarks/Olden/health/health
TEST-RESULT-compile: Total Execution Time: 0.0299 seconds (0.0732 wall clock)

TEST-RESULT-compile: 14924 Output/health.llvm.bc

TEST-RESULT-nat-time: program 0.710000

TEST-FAIL: llc /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: jit /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: cbe /MultiSource/Benchmarks/Olden/health/health

I used gcc/g++ 4.2, because 4.3 won't build many programs from llvm-test (strlen/strcpy undeclared, etc.).

Since CBE failed, I run this:
$ make bugpoint run-cbe
....

I get these bugpoint files, I am attaching them:
bugpoint-reduced-simplified.bc bugpoint.safe.bc bugpoint.test.bc

[edwintorok]

Created an attachment (id=1569) [details]
report file

On SVN r49248, x86-64 Linux:

---

========= '/MultiSource/Benchmarks/Olden/health/health' Program

---

TEST-PASS: compile /MultiSource/Benchmarks/Olden/health/health
TEST-RESULT-compile: Total Execution Time: 0.0299 seconds (0.0732 wall clock)

TEST-RESULT-compile: 14924 Output/health.llvm.bc

TEST-RESULT-nat-time: program 0.710000

TEST-FAIL: llc /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: jit /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: cbe /MultiSource/Benchmarks/Olden/health/health

Since all of llc,jit,cbe failed, I am not sure how to debug this.

[edwintorok]

Created an attachment (id=1569) [details]
report file

On SVN r49248, x86-64 Linux:

x86 Linux is ok.

[lattner]

Does it work with no optimizations? If so, it's an optimizer problem. If not, it's a front-end problem.

[edwintorok]

Does it work with no optimizations? If so, it's an optimizer problem. If not,
it's a front-end problem.

It doesn't work without optimizations, however GCC shows different results too with -m64 and -m32.

GCC binaries are valgrind clean (except for leaks).
But on llvm-gcc generated binary I see lots of use-of-undefined value:

==21927== Use of uninitialised value of size 8
==21927== at 0x4ECA3D5: __mpn_lshift (lshift.c:84)
==21927== by 0x4ED2B3B: __printf_fp (printf_fp.c:480)
==21927== by 0x4ECCB77: vfprintf (vfprintf.c:1559)
==21927== by 0x4ED59C9: printf (printf.c:35)
==21927== by 0x40115F: main (in /home/edwin/llvm-svn/llvm/projects/llvm-test/MultiSource/Benchmarks/Olden/health/noopt)
==21927==
==21927== Conditional jump or move depends on uninitialised value(s)
==21927== at 0x4ED2B5D: __printf_fp (printf_fp.c:484)
==21927== by 0x4ECCB77: vfprintf (vfprintf.c:1559)
==21927== by 0x4ED59C9: printf (printf.c:35)
==21927== by 0x40115F: main (in /home/edwin/llvm-svn/llvm/projects/llvm-test/MultiSource/Benchmarks/Olden/health/noopt)
==21927==
==21927== Use of uninitialised value of size 8
==21927== at 0x4ED2B70: __printf_fp (printf_fp.c:485)
==21927== by 0x4ECCB77: vfprintf (vfprintf.c:1559)
==21927== by 0x4ED59C9: printf (printf.c:35)
==21927== by 0x40115F: main (in /home/edwin/llvm-svn/llvm/projects/llvm-test/MultiSource/Benchmarks/Olden/health/noopt)
....

$ ./noopt 9 20 1
max_level=9 max_time=20 seed=1

Columbian Health Care Simulator

Working...
0
Getting Results
Done.

of people treated: 19.409472 people

Average length of stay: 68751.95 time units
Average # of hospitals visited: 5540.439453 hospitals

$ ./nat 9 20 1
max_level=9 max_time=20 seed=1

Columbian Health Care Simulator

Working...
0
Getting Results
Done.

of people treated: 100968.000000 people

Average length of stay: 13.22 time units
Average # of hospitals visited: 1.065060 hospital

$ ./nat32 9 20 1
max_level=9 max_time=20 seed=1

Columbian Health Care Simulator

Working...
0
Getting Results
Done.

of people treated: 101091.000000 people

Average length of stay: 13.22 time units
Average # of hospitals visited: 1.064912 hospitals

[edwintorok]

Does it work with no optimizations? If so, it's an optimizer problem. If not,
it's a front-end problem.

It doesn't work without optimizations, however GCC shows different results too
with -m64 and -m32.

GCC binaries are valgrind clean (except for leaks).
But on llvm-gcc generated binary I see lots of use-of-undefined value:

Some line numbers, built with llvm-gcc -O0 *.c -DTORONTO -o noopt -g -lm

Working...
0
Getting Results
Done.

==22064== Conditional jump or move depends on uninitialised value(s)
==22064== at 0x4ED1628: __printf_fp (printf_fp.c:380)
==22064== by 0x4ECCB77: vfprintf (vfprintf.c:1559)
==22064== by 0x4ED59C9: printf (printf.c:35)
==22064== by 0x4011CF: main (health.c:242)

[sunfishcode]

FWIW, this is a recent regression:

http://llvm.org/nightlytest/test.php?machine=259&night=5571

Most of the CBE failures in that list were due to an unrelated
bug which is now fixed, but olden/health is still outstanding.
I started investigating it but haven't gotten to the bottom of it yet.

[sunfishcode]

There's a problem with the return of the Results struct
by value from the get_results function. Results is declared
like this:

struct Results {
float total_patients;
float total_time;
float total_hosps;
};

[sunfishcode]

llvm-gcc is translating the struct return type to i128, which is
incorrect in this case.

Here's a reduced testcase:

struct foo {
float a;
float b;
float c;
};

struct foo bar(void) {
struct foo result = { 0.0, 0.0, 0.0 };
return result;
};

Function bar shouldn't have an i128 result type in the LLVM IR.

Devang, can you take a look at this?

[sunfishcode]

This is also related to the regression in
SingleSource/UnitTests/2006-01-23-UnionInit.c .

There, the return value in ucast_test is turned to i128. Offhand I'm
not sure that's wrong, but the code to store the return value uses
an alloca that's only 12 bytes (the size of the union), and the
code to set up the i128 return does an i128 load from that
memory. Among other consequences, mem2reg seems to think
that's an invitation for converting all the code to just ret undef.

[llvmbot]

I have patch that uses multiple value return for the example in comment #​10.

[llvmbot]

Function bar now returns { <4 x float>, float }

At -O2 I see,
define { <4 x float>, float } @​bar() nounwind {

entry:
ret <4 x float> zeroinitializer, float 0.000000e+00
}

However this does not fix mis-compilation. What is the appropriate llvm IR in this case ?

[sunfishcode]

This was fixed a while ago, and Olden/health now passes on x86-64.