This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Improve gimplification of constructors with RANGE_EXPRs (PR c++/82294, PR c++/87436)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Dec 2018 23:42:09 +0100
- Subject: Re: [PATCH] Improve gimplification of constructors with RANGE_EXPRs (PR c++/82294, PR c++/87436)
- References: <20181213231242.GE12380@tucnak> <alpine.LSU.2.20.1812141037180.1827@zhemvz.fhfr.qr> <20181214110751.GN12380@tucnak> <alpine.LSU.2.20.1812141222210.1827@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Dec 14, 2018 at 12:22:28PM +0100, Richard Biener wrote:
> > Still need to wait for the FE patch if I want to commit the testcases, those
> > depend on both patches.
> > I've added size32plus effective target to the larger test, as 384MB is too
> > much for 16 or 20 bit address targets.
> > And, I'll gather statistics on how often this makes a difference during
> > gimplification during my next bootstraps/regtests.
Besides those 2 new testcases it only made a difference on:
g++.dg/torture/pr60746.C
which has
{[0 ... 4]={[0 ... 1]={._vptr.One=&_ZTV3One + 16}}}
ctor (80 bytes), but only at -O0, so comparing the assembly in that case
is kind of pointless. If I modify the testcase to pass list_arry address
to external function and compile with -O2, the resulting assembly is
identical before/after this commit, as we inline the copy from the constant
ctor and unroll the loops.
If I modify it to:
class One
{
public:
virtual unsigned long getSize () const;
};
class Two
{
virtual int run ();
};
void bar (One (*)[2]);
int
Two::run ()
{
One list_arry[1000][2];
bar (list_arry);
return 0;
}
it is similar difference to the other testcases, either 16000 bytes
long .rodata initializer with memcpy from it, or a small loop.
Jakub