[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jul 5 23:57:11 UTC 2018


--- Comment #27 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Ben Crocker from comment #25)
> According to the Wikipedia article, the 970 is a Power ISA v2.03 (2002-2007)
> CPU,
> while VSX was not introduced until Power ISA v2.06 (February 2009) and
> So it seems to me that llc should recognize which version of the ISA each
> CPU implements, and that it should disallow combinations like
> -mcpu=970 -mattr=+altivec,+vsx

I don't think you can blame llvm for that. This looks perfectly acceptable to
me - you're specifying the cpu model (and that governs a lot more than just cpu
extensions), but then specify some extensions on top of it. It's not llvm's
fault that the cpu really can't do the extensions.
(fwiw on x86 this is perfectly acceptable too, and it's even more weird there,
for instance if you explicitly specify -avx but +f16c avx will get reenabled
nevertheless, since the latter option actually requires avx (or more
accurately, vex encoding) - you are responsible for specifying attributes which
make sense.)

Env vars to specify this are ok, but we should never manually enable attributes
which the cpu can't support (and certainly not by default...). Surely it's
possible to recognize these cpu features?
Also, maybe llvm would recognize the availability of these features on its own
nowadays correctly (as it does for x86)? Although I remember there were
problems due to LE/BE differentation on ppc.

You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180705/b79fb112/attachment.html>

More information about the mesa-dev mailing list