https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127086
Bug ID: 127086
Summary: RISC-V: mode-switching fails to hoist VXRM writes out
of some vectorized loops
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at ozlabs dot org
Target Milestone: ---
Created attachment 65428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65428&action=edit
VXRM test case
VXRM writes are expensive on the Ascalon CPU. When building cpu2017 x264 with
-flto, there are a few places where the VXRM write is inside a vectorized loop,
instead of being hoisted earlier eg refine_subpel -> pixel_avg:
4862c: 010e08b3 add a7,t3,a6
48630: 01f8b893 sltiu a7,a7,31
48634: 36089c63 bnez a7,489ac <refine_subpel+0x38d4>
48638: 01f83893 sltiu a7,a6,31
4863c: 36089863 bnez a7,489ac <refine_subpel+0x38d4>
48640: 00a05073 csrwi vxrm,0
48644: 02060107 vle8.v v2,(a2)
48648: 02050087 vle8.v v1,(a0)
4864c: 221120d7 vaaddu.vv v1,v1,v2
48650: 020580a7 vse8.v v1,(a1)
48654: 05c1 addi a1,a1,16
48656: 9636 add a2,a2,a3
48658: 9536 add a0,a0,a3
4865a: 9876 add a6,a6,t4
4865c: fd7598e3 bne a1,s7,4862c
<refine_subpel+0x3554>
And x264_me_search_ref -> pixel_avg:
51d90: 00b808b3 add a7,a6,a1
51d94: 01f8b893 sltiu a7,a7,31
51d98: 36089a63 bnez a7,5210c
<x264_me_search_ref+0x2e28>
51d9c: 01f5b893 sltiu a7,a1,31
51da0: 36089663 bnez a7,5210c
<x264_me_search_ref+0x2e28>
51da4: 00a05073 csrwi vxrm,0
51da8: 02060107 vle8.v v2,(a2)
51dac: 02070087 vle8.v v1,(a4)
51db0: 221120d7 vaaddu.vv v1,v1,v2
51db4: 020780a7 vse8.v v1,(a5)
51db8: 07c1 addi a5,a5,16
51dba: 966e add a2,a2,s11
51dbc: 976e add a4,a4,s11
51dbe: 95ca add a1,a1,s2
51dc0: fc9798e3 bne a5,s1,51d90
<x264_me_search_ref+0x2aac>
I used creduce and a bit of AI to create a test case, which I think replicates
the issue:
gcc -O3 -march=rv64gcv -flto -flto-partition=one *.c
executes 4096 vxrm writes
gcc -O3 -march=rv64gcv *.c
executes 257 vxmr writes
