This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/7145: g++ -O with structure initializer & return value optimization generates bad code
- From: "H. J. Lu" <hjl at lucon dot org>
- To: tlb at tlb dot org, jason at redhat dot com
- Cc: gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Mon, 1 Jul 2002 11:06:02 -0700
- Subject: Re: optimization/7145: g++ -O with structure initializer & return value optimization generates bad code
- References: <20020629213057.A21442@lucon.org> <200207011802.g61I2g573462@tlb.blackwells.net>
On Mon, Jul 01, 2002 at 11:02:41AM -0700, tlb@tlb.org wrote:
>
> > http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02277.html
>
> That's better. There isn't a big performance loss to disabling named
> return-value optimization for variables declared with
> initializer-lists, since you can't use an initializer-list for a
> struct with any sort of constructor. The return code should be just a
> bitwise copy.
>
>
> However, I don't think that solves the real problem. At all
> optimization levels but when the function doesn't get inlined, a
> return of a struct with an initializer-list seems to work OK (and
> probably faster) without your patch. It's only when inlining that it
> fails. So the real problem probably lurks in the inliner. The inliner
> probably already does a bunch of magic with trying to unify the return
> value and the caller's assignment, so it might be worth looking into
> how that interacts with unifying the callee's declaration and return
> value.
>
> Or maybe the plan should be not to attempt the named return value
> optimization when DECL_DECLARED_INLINE_P is true, since inlining will
> give better results anyway.
>
I believe Jason is looking into it now. I hope it will be fixed in gcc
3.1.1.
H.J.