[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 --- Comment #9 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #8) > I'd say it is a user error to invoke memcpy/memset etc. with pointers to > non-default address spaces, and for aggregate copies the middle-end should > ensure that the copying is not done using library calls; is that the case > and the problem was just that optab expansion was allowed for the structure > copies and the backend decided to use libcall in that case? Yes, the stringop selection mechanism chose libcall strategy. However, the call to memcpy is unavailable for non-default address space, so the middle-end expanded the call into most trivial byte-copy loop. The patch just teaches stringop selection to use optimized copy loop as a last resort with non-default address spaces instead.
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- I'd say it is a user error to invoke memcpy/memset etc. with pointers to non-default address spaces, and for aggregate copies the middle-end should ensure that the copying is not done using library calls; is that the case and the problem was just that optab expansion was allowed for the structure copies and the backend decided to use libcall in that case?
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #7 from Uroš Bizjak --- Fixed.
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:c6bff80d786919f2f64e8a9f3179d6d36888bdb3 commit r14-4418-gc6bff80d786919f2f64e8a9f3179d6d36888bdb3 Author: Uros Bizjak Date: Thu Oct 5 17:40:37 2023 +0200 i386: Improve memory copy from named address space [PR111657] The stringop strategy selection algorithm falls back to a libcall strategy when it exhausts its pool of available strategies. The memory area copy function (memcpy) is not availabe from the system library for non-default address spaces, so the compiler emits the most trivial byte-at-a-time copy loop instead. The compiler should instead emit an optimized copy loop as a fallback for non-default address spaces. PR target/111657 gcc/ChangeLog: * config/i386/i386-expand.cc (alg_usable_p): Reject libcall strategy for non-default address spaces. (decide_alg): Use loop strategy as a fallback strategy for non-default address spaces. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111657.c: New test.
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #5 from Uroš Bizjak ---
I have tried to compile with -mtune=nocona that has:
static stringop_algs nocona_memcpy[2] = {
{libcall, {{12, loop_1_byte, false}, {-1, rep_prefix_4_byte, false}}},
{libcall, {{32, loop, false}, {2, rep_prefix_8_byte, false},
{10, unrolled_loop, false}, {-1, libcall, false;
and compiler produces code as expected in both cases (use unrolled_loop when
rep movsq is unavailable):
foo:
movq%fs:0, %rdx
leaqt@tpoff(%rdx), %rsi
movl$30, %ecx
rep movsq
ret
bar:
xorl%edx, %edx
.L4:
movl%edx, %eax
movq%gs:s(%rax), %r9
movq%gs:s+8(%rax), %r8
movq%gs:s+16(%rax), %rsi
movq%gs:s+24(%rax), %rcx
movq%r9, (%rdi,%rax)
movq%r8, 8(%rdi,%rax)
movq%rsi, 16(%rdi,%rax)
movq%rcx, 24(%rdi,%rax)
addl$32, %edx
cmpl$224, %edx
jb .L4
addq%rdx, %rdi
movq%gs:s(%rdx), %rax
movq%rax, (%rdi)
movq%gs:s+8(%rdx), %rax
movq%rax, 8(%rdi)
ret
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Status|NEW |ASSIGNED
--- Comment #4 from Uroš Bizjak ---
Created attachment 56030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56030=edit
Propsed patch
Proposed patch declares libcall algorithm unavailable to non-default address
spaces and falls back to a loop if everything else fails. The following
testcase:
--cut here--
struct a { long arr[30]; };
__thread struct a t;
void foo (struct a *dst) { *dst = t; }
__seg_gs struct a s;
void bar (struct a *dst) { *dst = s; }
--cut here--
now compiles (-O2 -mno-sse) to:
foo:
movq%fs:0, %rdx
movl$30, %ecx
leaqt@tpoff(%rdx), %rsi
rep movsq
ret
bar:
xorl%eax, %eax
.L4:
movl%eax, %edx
addl$8, %eax
movq%gs:s(%rdx), %rcx
movq%rcx, (%rdi,%rdx)
cmpl$240, %eax
jb .L4
ret
(rep movsq copies only from the default ds: address space)
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #3 from Andrew Pinski --- The easiest way to improve this is to have decide_alg select loop for the have_as case if !TARGET_SSE && !TARGET_AVX... Which means this is a target issue.
