On 9/26/23 20:40, Toon Moene wrote:
/On 9/26/23 09:30, Richard Biener via Gcc wrote: />>//>>>/On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc />>>/<gcc@gcc.gnu.org> wrote: />>//>>>>/As I said at the end of the presentation, we have written a paper which />>>>/explains />>>>/our implementation in details. You can find it on the wiki page of the />>>>/Cauldron />>>>/(https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf
<https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf>).
/>>>//>>>/Thanks for the detailed presentation at the Cauldron. />>>//>>>/My personal summary is that I'm less convinced delaying lowering is />>>/the way to go. />>//>>/Thanks Sylvain for the quick summary of the discussion - it helps a />>/great deal now that the discussion is still fresh in our memory. />
I found time today to run some tests.
First of all, the result of the gcc test harness as applied to the top
of the complex/kvx branch in the https://github.com/kalray/gcc repository:
> https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/797627.html
<https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/797627.html>
I think there are several complex failures here that are not in
"standard" 12.2 release (for x86_64-linux-gnu).
We have removed some special cases for complex operations outside the cplxlower
pass (especially in tree-ssa-forwprop.cc), because of it ruined our efforts to
maintain it not lowered. So the performance is fine on the KVX target, but some
(SLP) vectorization cases are missed for other targets which do not exploit
complex patterns.
It may be interesting to add a conditions on theses cases rather than just
remove them.
I also compiled all of lapack-3.11.0 with that compiler and obtained the
same results as with gcc/gfortran 13.2:
--> LAPACK TESTING SUMMARY <--
Processing LAPACK Testing output found in the TESTING directory
SUMMARY nb test run numerical error other error
================ =========== ================= ================
REAL 1327023 0 (0.000%) 0
(0.000%)
DOUBLE PRECISION 1300917 6 (0.000%) 0
(0.000%)
COMPLEX 786775 0 (0.000%) 0
(0.000%)
COMPLEX16 787842 0 (0.000%) 0
(0.000%)
--> ALL PRECISIONS 4202557 6 (0.000%) 0 (0.000%)
Thank you! It doesn't surprise me because GCC still processed complex
operations like before when the backend does not exploit complex patterns.
Best regards,
Sylvain
