public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "chip at pobox dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/28831] [4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
Date: Mon, 06 Aug 2012 00:39:00 -0000	[thread overview]
Message-ID: <bug-28831-4-KJKt7lnT2z@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-28831-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831

Chip Salzenberg <chip at pobox dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chip at pobox dot com

--- Comment #15 from Chip Salzenberg <chip at pobox dot com> 2012-08-06 00:37:36 UTC ---
Ping.  I've just run into this with the tip of the gcc 4.7.1 branch.  Is there
a workaround?  Some way to label the struct as not needing to be stored? 
Something like __attribute__((noaddress));

We want to pass and return structs by value as current C++ style recommends,
but the extra register spills are dragging down performance.  For small key
classes we've switched to using big integers with masking functions, but for
larger ones there is no workaround that we know of.

Given this code:

extern val_t foo();
extern int bar(val_t);
int main() {
    return bar(foo());
}

When val_t is a struct of two int64_t on x86_64, the code has two extra stores:
>       movq    %rax, (%rsp)
>       movq    %rdx, 8(%rsp)
and the stack frame is larger and there is no tail call optimization.

When val_t is __int128 on x86_64, the code is optimal: tail call, no extra
stores, smaller stack frame (because there is no need to store the value).


  parent reply	other threads:[~2012-08-06  0:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-28831-4@http.gcc.gnu.org/bugzilla/>
2011-06-27 13:15 ` [Bug middle-end/28831] [4.3/4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org
2012-01-12 12:06 ` [Bug middle-end/28831] [4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org
2012-03-13 13:14 ` [Bug middle-end/28831] [4.5/4.6/4.7/4.8 " jakub at gcc dot gnu.org
2012-07-02 11:24 ` rguenth at gcc dot gnu.org
2012-08-06  0:39 ` chip at pobox dot com [this message]
2012-08-06  0:58 ` [Bug middle-end/28831] [4.6/4.7/4.8 " chip at pobox dot com
2012-08-14 22:51 ` chip at pobox dot com
2012-08-15 18:02 ` chip at pobox dot com
2012-08-18 15:34 ` hjl.tools at gmail dot com
2012-08-18 16:12 ` hjl.tools at gmail dot com
2013-04-12 15:16 ` [Bug middle-end/28831] [4.7/4.8/4.9 " jakub at gcc dot gnu.org
2013-09-05 20:04 ` chip at pobox dot com
2014-06-12 13:43 ` [Bug middle-end/28831] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
2014-06-12 17:09 ` [Bug middle-end/28831] [4.8/4.9/4.10 " chip at pobox dot com
2014-12-19 13:26 ` [Bug middle-end/28831] [4.8/4.9/5 " jakub at gcc dot gnu.org
2015-06-23  8:18 ` [Bug middle-end/28831] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
2015-06-26 19:53 ` [Bug middle-end/28831] [4.9/5/6 " jakub at gcc dot gnu.org
2015-06-26 20:27 ` jakub at gcc dot gnu.org
2021-03-22 11:05 ` [Bug middle-end/28831] [8/9/10/11 " rguenth at gcc dot gnu.org
2021-05-14  9:45 ` [Bug middle-end/28831] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:04 ` rguenth at gcc dot gnu.org
2022-05-27  9:33 ` [Bug middle-end/28831] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:29 ` jakub at gcc dot gnu.org
2023-07-07 10:28 ` [Bug middle-end/28831] [11/12/13/14 " rguenth at gcc dot gnu.org
2024-05-23 12:29 ` [Bug middle-end/28831] [11/12/13/14/15 " pinskia at gcc dot gnu.org
2024-05-23 13:10 ` mkretz at gcc dot gnu.org
2024-05-23 13:32 ` rguenther at suse dot de
2024-05-27  7:38 ` mkretz 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-28831-4-KJKt7lnT2z@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: link
Be 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).