On Tuesday, May 8, 2018 10:33:45 AM PDT Francisco Jerez wrote: > Kenneth Graunke <kenn...@whitecape.org> writes: > > > On Tuesday, May 8, 2018 1:23:32 AM PDT Eero Tamminen wrote: > >> Hi, > >> > >> On 08.05.2018 06:45, Matt Turner wrote: > >> > On Mon, May 7, 2018 at 8:02 PM, Brian Paul <bri...@vmware.com> wrote: > >> >> > >> >> I don't know when this started happening (I'll try bisecting tomorrow) > >> >> but > >> >> we're seeing a crash in ast_type_qualifier::validate_in_qualifier() in > >> >> -O3 > >> >> builds with gcc 5.4.0 on Ubuntu 16.04. > >> >> > >> >> Specifically, at ast_type.cpp:654: > >> >> > >> >> if ((this->flags.i & ~valid_in_mask.flags.i) != 0) { > >> >> > >> >> It seems to be the ~ operator/function which is implemented with an SSE > >> >> pxor > >> >> instruction. > >> >> > >> >> I found that this patch avoids the issue: > >> >> > >> >> diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h > >> >> index a1ec0d5..2e518ce 100644 > >> >> --- a/src/compiler/glsl/ast.h > >> >> +++ b/src/compiler/glsl/ast.h > >> >> @@ -474,7 +474,7 @@ enum { > >> >> > >> >> struct ast_type_qualifier { > >> >> DECLARE_RALLOC_CXX_OPERATORS(ast_type_qualifier); > >> >> - DECLARE_BITSET_T(bitset_t, 128); > >> >> + DECLARE_BITSET_T(bitset_t, 96); > >> >> > >> >> union flags { > >> >> struct { > >> >> > >> >> This probably prevents use of xmm instructions, but I haven't inspected > >> >> the > >> >> code. > >> >> > >> >> Is anyone else seeing this? > >> > > >> > Yes, it's https://bugs.freedesktop.org/show_bug.cgi?id=105497 > >> > > >> > I was surprised that we decided it's not worth working around. > >> > >> By making above part perform worse for everybody using -O3, or by > >> disabling vectorization optimization (enabled by -O3) just for > >> the buggy GCC version? > >> > >> (If that GCC version gets it wrong in this place, it may get it > >> wrong also elsewhere, so better turn that particular -O3 optimization > >> off completely.) > >> > >> Is there an upstream GCC bug report about that, which would tell > >> which GCC versions are affected? > >> > >> > >> - Eero > > > > I wouldn't worry about performance here, the AST code is basically > > never the hot path (even without shader cache, and now it's glacial). > > I was honestly surprised to see it start using xmm intrinsics. > > > > I agree that vectorizing this data structure is unlikely to make any > measurable performance difference in practice, but I think Eero still > has a point -- How do we know that this GCC optimization is not > miscompiling code elsewhere, potentially in a less frequently hit > codepath? I wouldn't take the risk of shipping a binary of Mesa built > with GCC 5.4 and -O3 even with this workaround. It may make more sense > to drop support for this GCC version (or as Eero suggested to turn the > optimization off).
I agree, it's probably safer to figure out which -fno-foo flag corresponds to this, and have the build system set that for GCC <= 5.4.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev