https://llvm.org/bugs/show_bug.cgi?id=25503
Bug ID: 25503
Summary: The instcombine pass cause 4 piglit/mesa tests to fail
in ppc64le
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: oded.gab...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15272
--> https://llvm.org/bugs/attachment.cgi?id=15272&action=edit
LLVM IR for original code, with instcombine and vmaxfp
Hi,
I'm working on enabling graphics (OpenGL) on ppc64le arch. This is done through
the llvmpipe driver in the mesa library. The llvmpipe driver converts TGSI
shader code into LLVM IR, by calling LLVM API functions that build the IR, then
call LLVM API to compile it as JIT function and then call that function when
necessary (multiple times).
To test mesa, we use another open source library called piglit, which contains
thousands of tests. Currently, I'm working on tests that fail on ppc64le but
pass on x86-64 (Haswell). I started with almost 600 such tests and now I'm down
to about 10.
I now found that out of those 10, 4 tests can succeed if I disable the use of
the instcombine pass. I made no other change in mesa, piglit or llvm code. This
means that the generated LLVM IR is the same (with or without the instcombine
pass), but the generated assembly is different.
Unfortunately, the generated assembly of graphic shaders is quite large (just
under 3400 assembly commands). That's why it is very difficult for me to
compare the generated assembly with this pass and without - the generated
assembly is very different.
I tried also to produce a "short" standalone IR file and reproduce the
problem with that, but to no avail.
I have two other findings I'd like to point out:
1. I thought that in the meantime, I could disable this pass in
llvmpipe and make those 4 tests pass. Unfrotunately, I found out that
even though it fixes those 4 tests, it causes a regression in about 30
other tests - which is very weird and something I find distributing.
2. There is another option to make those 4 tests pass, and that is to
disable use of the Altivec vmaxfp intrinsic (and instead use a couple of
generic
add/sub/shift IR commands). Now, I don't know why, but that fixes those 4
tests. Of course, that intrinsic is used in many many tests (almost
all of them), and most of the tests pass, so the problem is not in this
Altivec intrinsic itself, but probably in some combination of it and other
things.
I have attached 6 files:
- LLVM IR and generated assembly files for original code, with instcombine and
vmaxfp
- LLVM IR and generated assembly files for modified code, without instcombine
but with vmaxfp
- LLVM IR and generated assembly files for modified code, with instcombine but
without vmaxfp
Those files above were generated by mesa (see below on how to re-create them).
Because the bug is in a certain variant of the fragment shader, I removed all
the other shader codes from the above files because it is not relevant.
Therefore, they are shorter then the original dumps.
In addition, I would like to post here the steps to re-create this setup on a
POWER8, ppc64le machine. I'm using RHEL 7.2 internal release, but RHEL 7.1LE or
Fedora 21/22 ppc64le can be used as well. The important thing is that you need
a desktop GUI, such as GNOME, because you need xserver to run.
1. Clone LLVM, mesa and piglit repos:
1.1 git clone http://llvm.org/git/llvm.git
1.2 git clone git://anongit.freedesktop.org/mesa/mesa
1.3 git://anongit.freedesktop.org/git/piglit
1.4 export LLVM_ROOT=<llvm source folder>
1.5 export MESA_ROOT=<mesa source folder>
1.6 export PIGLIT_ROOT=<piglit source folder>
1.7 export LIBGL_ALWAYS_SOFTWARE=1
2. Build LLVM
2.1 mkdir ~/myllvmbuild ; cd ~/myllvmbuild
2.2 $LLVM_ROOT/configure --disable-dependency-tracking --prefix=$HOME/.local
--with-extra-ld-options=-Wl,-Bsymbolic,--default-symver --enable-targets=host
--enable-bindings=none --enable-debug-runtime --enable-jit --enable-shared
--enable-optimized --disable-clang-arcmt --disable-clang-static-analyzer
--disable-clang-rewriter --disable-assertions --disable-docs --disable-libffi
--disable-terminfo --disable-timestamps
2.3 make -j8 ; make install
3. Build mesa
3.1 mkdir ~/mesa_debug_build ; cd ~/mesa_debug_build
3.2 $MESA_ROOT/autogen.sh --disable-dependency-tracking
--prefix=$HOME/.local --enable-selinux --enable-osmesa
--with-dri-driverdir=$HOME/.local/lib/dri --enable-egl --disable-gles1
--enable-gles2 --disable-xvmc --disable-dri3 --with-egl-platforms=x11,drm
--enable-shared-glapi --enable-gbm --disable-opencl --enable-glx-tls
--enable-texture-float=yes --enable-gallium-llvm --enable-llvm-shared-libs
--enable-dri --with-gallium-drivers=svga,swrast --with-dri-drivers=swrast
--with-llvm-prefix=$HOME/.local --enable-debug CFLAGS="-O0 -ggdb3"
CXXFLAGS="-O0 -ggdb3"
3.3 make -j8
3.4 export LIBGL_DRIVERS_PATH=$HOME/mesa_debug_build/lib/gallium
3.5 export LD_LIBRARY_PATH=$HOME/mesa_debug_build/lib:$HOME/.local/lib
4. Build piglit
4.1 mkdir ~/piglit_build ; cd ~/piglit_build
4.2 export PIGLIT_BUILD_DIR=$HOME/piglit_build
4.3 ccmake $PIGLIT_ROOT -DOPENGL_INCLUDE_DIR=$MESA_ROOT/include
4.3.1 inside ccmake screen, make sure you have all dependencies installed.
If not, you can find all of them in rpmfind website (for rpm based
distributions).
4.3.2 press 'c' twice, then 'g' to generate the config
4.4 make -j8
5. Make sure everything is configured
5.1 glxinfo | grep OpenGL
5.2 Make sure you see in the results:
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel
OpenGL core profile shading language version string: 3.30
6. Run the test
6.1 ~/piglit_build/bin/arb_blend_func_extended-fbo-extended-blend -auto
6.2 The expected output is:
Probe color at (5,5)
Expected: 0.875000 0.250000 0.500000 0.375000
Observed: 0.749020 0.125490 0.250980 0.250980
For src/dst 4 3 0
PIGLIT: {"result": "fail" }
Additional tips:
- You can dump the LLVM IR by exporting GALLIVM_DEBUG=ir
- You can dump the generated assembly by exporting GALLIVM_DEBUG=asm
- You can change DEBUG_EXECUTION define in lp_bld_tgsi_soa.c to 1 to dump
values from the shader code. However, this makes the problem go away :(
Probably because it rearranges the code so the bug disappears.
- llvmpipe driver is located at $MESA_ROOT/src/gallium/drivers/llvmpipe
- Additional auxiliary llvmpipe files are located at
$MESA_ROOT/src/gallium/auxiliary/gallivm
- lp_bld_init.c contains the code that chooses which passes we are using (and
does other initialization commands)
- From my debugging, the problem appears to be located *after* the loop_exit:
label in the LLVM IR file, meaning all values up to that point appears to be
correct. I'm also basing this on the fact that vmaxfp is used only after that
label. This is 100% certain, but I thought I should mentioned it.
- The fragment shader code is called in 3 places, but if you want to debug it,
you can just put breakpoint at lp_rast_shade_tile() at line that starts with:
variant->jit_function[RAST_WHOLE] - That's the entry point to the fragment
shader jit function
That's about it,
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
