public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "scovich at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/49035] New: Avoid setting up stack frame for short, hot code paths Date: Wed, 18 May 2011 03:03:00 -0000 [thread overview] Message-ID: <bug-49035-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49035 Summary: Avoid setting up stack frame for short, hot code paths Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned@gcc.gnu.org ReportedBy: scovich@gmail.com I often find myself writing functions of the following form: void foo () { if (common_case) { /* do a little work and return */ } /* uncommon case: do a lot of work, call functions, etc. */ } The resulting assembly code always sets up a stack frame in the function prologue, even though the function usually executes as a leaf using few (or zero) of the callee-save registers and stack slots it saves. Here's an example which is only slightly contrived: === rfe.cpp ============ struct link { link* prev; long go_slow; void frob(link* parent, link* grandparent); }; link* foo(link* list) { link* prev = list->prev; while (__builtin_expect(prev->go_slow, 0)) { link* pprev = __sync_lock_test_and_set(&prev->prev, 0); pprev->frob(prev, list); prev = pprev; } return prev; } === rfe.cpp ============ Compiling the above with `x86_64-unknown-linux-gnu-g++-4.5.2 -O3 -S' yields _Z3fooP4link: .LFB0: movq %rbx, -24(%rsp) movq %rbp, -16(%rsp) movq %rdi, %rbx movq %r12, -8(%rsp) subq $24, %rsp movq (%rdi), %rax cmpq $0, 8(%rax) jne .L8 .L2: movq (%rsp), %rbx movq 8(%rsp), %rbp movq 16(%rsp), %r12 addq $24, %rsp ret .L8: xorl %r12d, %r12d .L6: movq %r12, %rbp xchgq (%rax), %rbp movq %rbx, %rdx movq %rax, %rsi movq %rbp, %rdi call _ZN4link4frobEPS_S0_ cmpq $0, 8(%rbp) jne .L4 movq %rbp, %rax jmp .L2 .L4: movq %rbp, %rax jmp .L6 Ideally, it would look like this instead: _Z3fooP4link: .LFB0: ;; *** hot path executes as leaf *** movq (%rdi), %rax cmpq $0, 8(%rax) jne .L8 ret .L8: ;; *** set up stack frame *** movq %rbx, -24(%rsp) movq %rbp, -16(%rsp) movq %rdi, %rbx movq %r12, -8(%rsp) subq $24, %rsp ;; *** xorl %r12d, %r12d .L6: movq %r12, %rbp xchgq (%rax), %rbp movq %rbx, %rdx movq %rax, %rsi movq %rbp, %rdi call _ZN4link4frobEPS_S0_ cmpq $0, 8(%rbp) jne .L4 ;; *** tear down stack frame *** movq %rbp, %rax movq (%rsp), %rbx movq 8(%rsp), %rbp movq 16(%rsp), %r12 addq $24, %rsp ;; *** ret .L4: movq %rbp, %rax jmp .L6 The effect can sometimes be simulated using an inlined foo which includes the fast path and a call to the (non-inlined) slow path, but the whims of function inlining often conspire against it even when callers are able to inline foo (e.g. foo is not a library function). There's probably some overlap with partial inlining here: the ideal case essentially splits the slow path off into its own function (called using tail recursion); presumably partial inlining would inline the fast path while having all callers jump to the same copy of the slow path function. However, the optimization is arguably useful even if foo is never inlined at all. Thoughts? Ryan
next reply other threads:[~2011-05-18 2:54 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-18 3:03 scovich at gmail dot com [this message] 2011-05-18 3:38 ` [Bug middle-end/49035] " scovich at gmail dot com 2011-05-18 5:26 ` pinskia 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-49035-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).