This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Short Displacement Problems.
- From: Jan Hubicka <jh at suse dot cz>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Zack Weinberg <zack at codesourcery dot com>,Naveen Sharma Noida <naveens at noida dot hcltech dot com>,Joern Rennecke <joern dot rennecke at superh dot com>, law at redhat dot com,Alexandre Oliva <aoliva at redhat dot com>, bernds at redhat dot com,gniibe at m17n dot org, Richard Henderson <rth at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 May 2002 19:43:41 +0200
- Subject: Re: Short Displacement Problems.
- References: <20020530165659.GE9581@atrey.karlin.mff.cuni.cz> <200205301729.KAA03865@atrus.synopsys.com>
>
> > In my experiments I've been simply using ADRESSOF as kind of "ticket for
> > stack slot" and it appears to work pretty well up to the reload. Major
> > problem is that lowering the code may result in CSEable expressions.
>
> Right, but the problem is that ADDRESSOF doesn't work in general for
> structs. The result is a huge penalty in C++ for temporary objects
> with more than one data member, compared to with one.
In my simple minded patch it did - I simply assigned ADDRESSOF for a
struct (and each object on the stack) and purge_adressof homed the
structure on stack when addressof reference survived. At least we
didn't allocate stack slots for structs never used.
But what we really need is scalar replacement I guess and that would
take more work.
Honza
>
> Stack slot assignment probably isn't worth the bother unless it works
> for structs, not just objects that have a mode that GCC knows about.