public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "brian.grayson at sifive dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100348] New: RISC-V extra pointer adjustments for memcpy() from glibc Date: Thu, 29 Apr 2021 23:40:25 +0000 [thread overview] Message-ID: <bug-100348-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100348 Bug ID: 100348 Summary: RISC-V extra pointer adjustments for memcpy() from glibc Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: brian.grayson at sifive dot com Target Milestone: --- Created attachment 50714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50714&action=edit Source C code for trimmed example The wordcopy_fwd_aligned() portion of glibc contains generated code like the following assembly dump: .L16: ld a6,16(a1) addi a3,a5,24 sd a4,0(a0) .L15: ld a4,24(a1) addi a0,a5,32 sd a6,0(a3) .L14: ld a6,32(a1) addi a3,a5,40 sd a4,0(a0) .L13: ld a4,40(a1) addi a0,a5,48 sd a6,0(a3) .L12: ld a6,48(a1) addi a3,a5,56 sd a4,0(a0) For some reason, gcc is able to do the proper immediate-offset thinking so that the loads use different offsets and a fixed base register (until we get to the bottom of the loop, and bump the a1 pointer), but for the stores, it bumps the pointer each time. This adds 50% more instructions to the innermost loop of memcpy() arguably a bit of code we should try to have optimal code for. I've simplified the code here, to make it about as small as it can be and still demonstrate the issue. Here is the generated assembly, with my commentary to the right in comments: .file "simple.c" .option nopic .attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0" .attribute unaligned_access, 0 .attribute stack_align, 16 .text .align 1 .globl not_really_wordcopy_fwd_aligned .type not_really_wordcopy_fwd_aligned, @function not_really_wordcopy_fwd_aligned: andi a5,a2,3 li a4,2 beq a5,a4,.L2 li a4,3 beq a5,a4,.L3 li a4,1 beq a5,a4,.L20 bne a2,zero,.L21 ret .L20: addi a2,a2,-1 ld a3,0(a1) bne a2,zero,.L22 .L10: sd a3,0(a0) .L23: ret .L3: ld a3,0(a1) addi a4,a1,-40 addi a5,a0,-48 addi a2,a2,5 addi a1,a1,-8 addi a7,a0,-16 j .L7 .L11: sd a3,32(a5) // Uses an immediate offset off of a5. Good. ld a3,32(a4) addi a7,a5,32 addi a1,a4,32 .L9: sd a3,40(a5) // Uses an immediate offset off of a5. Good again. ld a3,40(a4) addi a0,a5,48 // Uh-oh, bumping a pointer to be a5+48. .L7: sd a3,0(a0) // Uh-oh, using the pointer. Why not 48(a5)? ld a6,48(a4) addi a0,a5,56 mv a3,a4 mv a5,a7 mv a4,a1 .L6: sd a6,0(a0) addi a2,a2,-4 ld a3,56(a3) mv a0,a5 bne a2,zero,.L11 sd a3,0(a0) j .L23 .L2: ld a6,0(a1) addi a3,a1,-48 addi a2,a2,6 addi a4,a1,-16 addi a5,a0,-24 j .L6 .L22: addi a4,a1,8 mv a5,a0 j .L11 .L21: ld a3,0(a1) mv a4,a1 addi a5,a0,-8 addi a1,a1,32 addi a7,a0,24 j .L9 .size not_really_wordcopy_fwd_aligned, .-not_really_wordcopy_fwd_aligned .ident "GCC: (SiFive GCC-Metal 10.2.0-2020.12.9) 10.2.0" I realize that the different paths to L7 make this a bit confusing, but it seems that since the only path to L7 is through the code at L3 or through the fallthrough path where it is currently adjusting the pointer, the proper adjustments could be made before, outside the loop, instead of each time. In the full memcpy() source code, this behavior occurs multiple times, roughly for every store, as shown at the top of this bug report.
next reply other threads:[~2021-04-29 23:40 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-29 23:40 brian.grayson at sifive dot com [this message] 2021-04-30 19:01 ` [Bug target/100348] " wilson at gcc dot gnu.org 2021-04-30 19:01 ` wilson at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-100348-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).