[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&action=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.