doduc Polyhedron 2005 benchmark segfaults when built with -msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns

[llvmbot]

Bugzilla Link	10891
Resolution	FIXED
Resolved on	Sep 24, 2011 06:40
Version	trunk
OS	MacOS X
Depends On	llvm/llvm-bugzilla-archive#10907
Reporter	LLVM Bugzilla Contributor

Extended Description

At r139290, the doduc Polyhedron 2005 benchmark built with...

/sw/lib/gcc4.6/bin/gfortran -fplugin=/sw/lib/gcc4.6/lib/dragonegg.so -msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns doduc.f90 -o doduc

segfaults during execution...

[MacPro:pb05/lin/source] howarth% ./doduc
MAIN : FIN S00002
MAIN : FIN S00001
MAIN : FIN S00011
MAIN : FIN S00022
TEMPS = 33.00000000 , NITERA : 1
TEMPS = 34.00010010 , NITERA : 190
TEMPS = 35.00473527 , NITERA : 952
TEMPS = 36.00310365 , NITERA : 1518
TEMPS = 37.00295766 , NITERA : 1790
TEMPS = 38.00173154 , NITERA : 2096
TEMPS = 39.00214237 , NITERA : 2407
TEMPS = 40.00105777 , NITERA : 2715
TEMPS = 45.00109540 , NITERA : 4262
TEMPS = 50.00123507 , NITERA : 5885
TEMPS = 55.00131498 , NITERA : 7531
TEMPS = 60.00042238 , NITERA : 9419
Segmentation fault

which backtraces as...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007ffb5fbfe9b0
s00061_ (i=<value temporarily unavailable, due to optimizations>, hv=@0x7fff5fbfed30, hvt=@0x7fff5fbfed28, hvme=<value temporarily unavailable, due to optimizations>, hvms=<value temporarily unavailable, due to optimizations>, ynu=@0x7fff5fbfed10, tfl=@0x7fff5fbfed40, re=<value temporarily unavailable, due to optimizations>, iopt=@0x10001ffb4, dtfl=@0x7fff5fbfed00) at doduc.f90:568
568 y1 = y(i1)
(gdb) bt
#​0 s00061_ (i=<value temporarily unavailable, due to optimizations>, hv=@0x7fff5fbfed30, hvt=@0x7fff5fbfed28, hvme=<value temporarily unavailable, due to optimizations>, hvms=<value temporarily unavailable, due to optimizations>, ynu=@0x7fff5fbfed10, tfl=@0x7fff5fbfed40, re=<value temporarily unavailable, due to optimizations>, iopt=@0x10001ffb4, dtfl=@0x7fff5fbfed00) at doduc.f90:568
#​1 0x000000010000e1b6 in s00013_ () at doduc.f90:1150
Previous frame inner to this frame (gdb could not unwind past this frame)

[llvmbot]

Adding -fno-tree-vectorize eliminates the run-time segfault when compiling with -msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns.

[llvmbot]

The run-time segfault in doduc can be reproduce with...

de-gfortran46 -msse4 -ffast-math -O2 -fplugin-arg-dragonegg-enable-gcc-optzns -ftree-vectorize doduc.f90 -o dodu

but doesn't occur with...

de-gfortran46 -msse4 -ffast-math -O1 -fplugin-arg-dragonegg-enable-gcc-optzns -ftree-vectorize doduc.f90 -o doduc

or

de-gfortran46 -msse4 -O2 -fplugin-arg-dragonegg-enable-gcc-optzns -ftree-vectorize doduc.f90 -o doduc

so '-msse4 -ffast-math -O2 -fplugin-arg-dragonegg-enable-gcc-optzns -ftree-vectorize' appears to be the minimal flag that trigger this PR.

[llvmbot]

Does it work now?

[llvmbot]

This issue still occurs at r139311.

[llvmbot]

Is this on a 32 bit machine or a 64 bit machine?

[llvmbot]

This is on x86_64-apple-darwin11.

[llvmbot]

This issue can also be reproduced with...

de-gfortran46 -msse4 -funsafe-math-optimizations -ffinite-math-only -O2 -fplugin-arg-dragonegg-enable-gcc-optzns -ftree-vectorize doduc.f90 -m32-o doduc

at both -m32 or -m64.

[llvmbot]

The miscompile seems to be in the function s00017_. By the way, I don't get a
segfault. Instead I see differences in the intermediate results and slower
convergence.

[llvmbot]

Fixing llvm/llvm-bugzilla-archive#10907 doesn't seem to have helped much.

[llvmbot]

It seems that s00002_ is being miscompiled.

[llvmbot]

At r139660, the doduc test appears to pass...

Value= 2000.0024807 Target= 2000.0024122 Tolerance=0.10000000000E-01
Value= 529843 Target= 533050 Tolerance= 5000

doduc PASSED 2 tests - no failures

when compiled with de-gfortran46 -msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns. The execution time is about 10% slower than if -fno-tree-vectorize is also passed.
Regarding the intermediate values, I would note that...

gfortran-fsf-4.6 -msse4 -ffast-math -funroll-loops -O3 -fno-tree-vectorize doduc.f90 -o doduc

and

gfortran-fsf-4.6 -msse4 -ffast-math -funroll-loops -O3 doduc.f90 -o doduc

produce different intermediate values for TEMPS and NITERA as well with stock FSF gcc.

[llvmbot]

I agree that with top-of-tree doduc is executing correctly, but slowly.

[llvmbot]

We still have a 10% speed degradation in the doduc run-time at r140001 when compiling with dragonegg gcc-4.6 using...

-msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns

33.794u 0.007s 0:33.80 99.9% 0+0k 0+0io 0pf+0w

or

-msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns -fno-tree-vectorize

33.653u 0.007s 0:33.66 99.9% 0+0k 0+0io 0pf+0w

compare to compiling with...

-msse4 -ffast-math -funroll-loops -O3

30.085u 0.007s 0:30.09 99.9% 0+0k 0+0io 0pf+0w

which thus appears to be unrelated to vectorization.

[llvmbot]

I added a new vector optimization to LLVM codegen that may help.

[llvmbot]

The doduc run time is reduced from 33.32s to 27.68s at r140387 for -msse4 -ffast-math -funroll-loops -O3 -fplugin-arg-dragonegg-enable-gcc-optzns with FSF gcc 4.6.2svn.