[Bug middle-end/28831] [4.3/4.4/4.5/4.6/4.7 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[Bug middle-end/28831] [4.3/4.4/4.5/4.6/4.7 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.6                       |4.4.7

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-27 12:12:43 UTC ---
4.3 branch is being closed, moving to 4.4.7 target.

[Bug middle-end/28831] [4.4/4.5/4.6/4.7 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 12:05:26 UTC ---
(In reply to comment #5)
> Here's another example:
> 
> struct A { int i[100]; };
> void f(struct A);
> int main()
> {
>   f((struct A){1});
> }
> 
> Here we build up the compound literal on the stack and then copy it into the
> argument slot.
> 
> This seems to be a problem with GIMPLE, as there's no way to represent that we
> want a particular temporary object to live in the argument slot.
> 
> This is both more and less of a problem for C++, as it has many more temporary
> struct objects, but also has pass-by-reference (and the ABI does transparent
> pass-by-reference for non-POD structs).

I suppose it would be easy to add a decl flag DECL_ARGUMENT_SLOT, but of course
defering its allocation until we expand the call (if the argument is passed
by value) is going to be interesting, as we basically have the argument
setup visible in gimple.  For your testcase it's passed by reference it
seems so that would be ok and we can simply avoid the argument slot
allocation and copying at expansion time.

[Bug middle-end/28831] [4.5/4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:45:24 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug middle-end/28831] [4.5/4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 11:23:15 UTC ---
The 4.5 branch is being closed, adjusting target milestone.

[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

[chip at pobox dot com]

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).

[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

[chip at pobox dot com]

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

--- Comment #16 from Chip Salzenberg <chip at pobox dot com> 2012-08-06 00:57:13 UTC ---
Addendum: In cut down test cases where I only pass by value or only return by
value, but not both, I find no extra stores, which is good; but I still find a
lot of unnecessary frame allocation (either $24 or $40, depending), and tail
call is still missing.

[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

[chip at pobox dot com]

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

--- Comment #17 from Chip Salzenberg <chip at pobox dot com> 2012-08-14 22:50:01 UTC ---
The patch posted in Bug 20020 prevents missed optimization for 128-bit
structures on x86_64.  So this bug does seem to be all about the BLKmode.

[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

[chip at pobox dot com]

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

--- Comment #18 from Chip Salzenberg <chip at pobox dot com> 2012-08-15 18:00:39 UTC ---
What will it take to get this fixed?  Pass by value is Big in C++11 style, with
move semantics designed to tie right into the optimization that's being missed
here.

This is sucking a lot for C++.

[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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |ubizjak at gmail dot com

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> 2012-08-18 15:32:41 UTC ---
With GCC 3.4, -march=i686 will allocate stack and copy f() return
to g().  With newer GCC, the same thing also happens with -march=i386.

[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

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> 2012-08-18 16:10:43 UTC ---
With -maccumulate-outgoing-args, GCC 3.4 will also make
a copy.

[Bug middle-end/28831] [4.7/4.8/4.9 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:16:00 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug middle-end/28831] [4.7/4.8/4.9 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[chip at pobox dot com]

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

--- Comment #22 from Chip Salzenberg <chip at pobox dot com> ---
Anyone?  Bueller?

[Bug middle-end/28831] [4.7/4.8/4.9/4.10 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug middle-end/28831] [4.8/4.9/4.10 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[chip at pobox dot com]

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

--- Comment #24 from Chip Salzenberg <chip at pobox dot com> ---
In 4.8.2 (Ubuntu trusty), the copy is finally elided.  Good job!  But stack
space is still allocated for the copy that is not made.  So it's not all fixed.

[Bug middle-end/28831] [4.8/4.9/5 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug middle-end/28831] [4.8/4.9/5/6 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug middle-end/28831] [4.9/5/6 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug middle-end/28831] [4.9/5/6 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug middle-end/28831] [8/9/10/11 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that if we'd want to "preallocate" (or re-use) variables for argument
slots we have to properly arrange them according to the ABI.  Consider
a function taking more than just a single argument [passed on stack] which
we might still able to handle optimally [with greater difficulty].

Jasons C++ example expands from

  D.2368 = {};
  D.2368.i[0] = 1;
  f (D.2368);

if you modify that to

struct A { int i[100]; };
void f(int i, struct A, int j);
int main()
{
  f(0, (struct A){1}, 2);
}

then on i?86 both extra arguments are passed on the stack as well but
RTL expansion sees again

  D.2370 = {};
  D.2370.i[0] = 1;
  f (0, D.2370, 2);

but clearly we cannot just allocate D.2370 in a random place if it is
passed on the stack (on i?86 it's passed by reference).  For example

struct A { int i[2]; };
void f(struct A);
int main()
{
  f((struct A){1});
}

expanded as

  MEM <char[4]> [(struct A *)&D.1960 + 4B] = {};
  D.1960.i[0] = 1;
  f (D.1960);

is passed on the stack though.  So if we want to expose anything on GIMPLE
then we have to make the argument space on the stack distinct from random
stack variables.

[Bug middle-end/28831] [9/10/11/12 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug middle-end/28831] [9/10/11/12 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #38 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug middle-end/28831] [10/11/12/13 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #39 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug middle-end/28831] [10/11/12/13 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug middle-end/28831] [11/12/13/14 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkretz at gcc dot gnu.org

--- Comment #42 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115204 has been marked as a duplicate of this bug. ***

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[mkretz at gcc dot gnu.org]

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

--- Comment #43 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
I see this issue in SIMD programming. Example (on x86_64 with only '-O2', i.e.
without AVX512) https://compiler-explorer.com/z/K64djP356:

typedef int V __attribute__((vector_size(64)));

V gen();

void g0(V const&, V const&);
void g1(V, V);

void constref()
{
  g0(gen(), gen());
}

void byvalue()
{
  g1(gen(), gen());
}

Both the 'constref' and 'byvalue' cases copy every V argument before calling
g0/g1.

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenther at suse dot de]

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

--- Comment #44 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 23 May 2024, mkretz at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
> 
> --- Comment #43 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
> I see this issue in SIMD programming. Example (on x86_64 with only '-O2', i.e.
> without AVX512) https://compiler-explorer.com/z/K64djP356:
> 
> typedef int V __attribute__((vector_size(64)));
> 
> V gen();
> 
> void g0(V const&, V const&);
> void g1(V, V);
> 
> void constref()
> {
>   g0(gen(), gen());
> }
> 
> void byvalue()
> {
>   g1(gen(), gen());
> }
> 
> Both the 'constref' and 'byvalue' cases copy every V argument before calling
> g0/g1.

The copy on GIMPLE is due to IL constraints:

  _10 = gen ();

  <bb 4> :
  D.2805 = _10;
  g0 (&D.2805, &D.2806);

when the call has a register type return value the LHS of the call
statement has to be a register (SSA name).  But the argument to
g0 has to be memory, so we get the extra copy.  Now, w/o AVX512
that "register" doesn't work out and we allocate it to memory
causing a memory-to-memory copy.

That's also because in vector lowering we do not lower those
register-to-memory stores (doing that would possibly help a bit,
as would more clever expansion of the copy or more clever
expanding of _10)

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[mkretz at gcc dot gnu.org]

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

--- Comment #45 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
(Alright, let's ignore the "oversized" vector for now - my
std(::experimental)::simd implementation doesn't use them anyway. It uses
aggregates of vectors matching the target SIMD width. FWIW, I pass all these by
const-ref in my implementation and still see way too many copies. But I'd have
to dig deeper for a relevant test case.)

But... just for a low-hanging fruit / partial solution idea here: Given

void a(auto, auto); // i.e. by-value

a(b(), c())

the two calls to b() and c() will store their returned objects on the stack.
Subsequently, when 'a' is called, instead of unconditionally moving the stack
pointer and copying the arguments to the desired locations, check whether
  1. the objects returned from b() and c() can be modified by 'a' in-place
without
     affecting following code (last use of object returned by b() and c()), and
  2. by chance, the arguments are already in the right place (i.e. if the stack
     pointer is left unmodified).
If both are true, elide the copies.

Next step? Predict the best stack location for return objects so that the above
heuristic is true in more cases.