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). > --Ken > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
