Hi,
On 08.05.2018 20:33, Francisco Jerez wrote:
Kenneth Graunke <kenn...@whitecape.org> writes:
On Tuesday, May 8, 2018 1:23:32 AM PDT Eero Tamminen wrote:
On 08.05.2018 06:45, Matt Turner wrote:
On Mon, May 7, 2018 at 8:02 PM, Brian Paul <bri...@vmware.com> wrote:
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?
>>
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 tried to find related GCC bug, but only GCC alignment bugs were
either for GCC 4.4 or older, or for ARM:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271
(ARM SIMD instruction issue fixed in GCC v6.0 -> is anybody testing
Mesa with GCC -O3 on ARM?)
However, I found a related Glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21120
Which was fixed in 2017, in Glibc v2.26.
NOTE: When optimizations are enabled, GCC will assume that all
incoming memory addresses (stack, malloc etc) have a certain
minimum alignment (nowadays 16-bytes), and doesn't do any
alignment for them in the callee.
There's no mention in the bug where the memory given to x86 SIMD
instructions (that require 16-byte alignment) came from. Is it
from stack, or from malloc()?
- Eero
PS. As bug is with shader-db test, I don't think problem is linking with
objects from other compilers, or too old GCC versions, or allocations
coming from auto-generated JIT / hand-written / old assembly code,
which don't implement the nowadays required 16-byte alignment.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
