[Bug target/105782] New: [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[Bug target/105782] New: [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[koachan+gccbugs at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

            Bug ID: 105782
           Summary: [sparc64] Emission of questionable movxtod/movdtox
                    with -mvis3
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: koachan+gccbugs at protonmail dot com
  Target Milestone: ---

Created attachment 53055
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53055&action=edit
The problematic function, adapted for standalone compilation

Hello, I found out that the blake2b implementation in monocypher runs much
slower on a SPARC T4 when compiled with `-O3 -mvis3`, as opposed to plain
`-O3`:

With plain -O3:  Blake2b : 184 megabytes  per second
With -O3 -mvis3: Blake2b : 118 megabytes  per second

(Results are from monocypher's `make speed` benchmark)

Looking at the generated assembly, it seems that when the code is compiled with
-mvis3, GCC emits a lot of questionable `movxtod`/`movdtox` instructions?

I'm using sparc64-linux-gnu-gcc (GCC) 12.1.0.

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You can check -fopt-info-vec for vectorization.  Note the sparc backend doesn't
implement any of GCCs vectorizer cost modeling hooks.

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[koachan+gccbugs at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

--- Comment #2 from Koakuma <koachan+gccbugs at protonmail dot com> ---
Created attachment 53066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53066&action=edit
Vectorization log from -fopt-info-vec-all

(In reply to Richard Biener from comment #1)
> You can check -fopt-info-vec for vectorization.

I tried recompiling it with -fopt-info-vec-all and I got a long message that
ends with:

> blake2b-monocypher-standalone.c:75:18: note: Cost model analysis: 
> blake2b-monocypher-standalone.c:75:18: note: Cost model analysis for part in loop 0:
>   Vector cost: 2282
>   Scalar cost: 181
> blake2b-monocypher-standalone.c:75:18: missed: not vectorized: vectorization is not profitable.

So I dont think that GCC vectorized that function.

Also, I tried recompiling with -fno-tree-optimize and it doesn't improve
anything.
Seems like the problem isn't in the vectorizer?
(it still produces the same slow code with many `movxtod`/`movdtox`s)

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-06-07
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I guess that, under high register pressure, the register allocator rather uses
floating-point registers than spllling values on the stack.

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[koachan+gccbugs at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

--- Comment #4 from Koakuma <koachan+gccbugs at protonmail dot com> ---
(In reply to Eric Botcazou from comment #3)
> I guess that, under high register pressure, the register allocator rather
> uses floating-point registers than spllling values on the stack.

I suppose so?
However, I found that when compiling the source from the previous comment with
-mvis3, it emits over 1400 movXtoY instructions, resulting in 1300-ish extra
instructions compared to the version without VIS 3, which seem to be quite
weird to me.

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Investigating.