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
