Re: small C++ classes

Jason Merrill <jason@cygnus.com>
13 Dec 1997 12:04:09 -0500

          From comp.compilers

Related articles
small C++ classes geurts@retarget.com (Werner Geurts) (1997-12-12)
Re: small C++ classes jason@cygnus.com (Jason Merrill) (1997-12-13)
Re: small C++ classes jason@cygnus.com (Jason Merrill) (1997-12-15)
Re: small C++ classes shankar@powertelglobal.com (Shankar Unni) (1997-12-19)
| List of all articles for this month |

From: Jason Merrill <jason@cygnus.com>
Newsgroups: comp.compilers
Date: 13 Dec 1997 12:04:09 -0500
Organization: Cygnus Solutions, Sunnyvale, CA
References: 97-12-097
Keywords: C++, optimize

>>>>> Werner Geurts <geurts@retarget.com> writes:


> I am looking for information on storage allocation for small C++
> classes like point or complex, that contain only a few scalar data
> members. Are there any C++ compilers that allocate (the members of)
> such object to the register set instead of to memory?


I remember a cfront post-processor called cback that did just that, by
splitting up temporary objects into multiple C variables.


I believe that KAI C++ also does pretty well at this optimization.


> Under what conditions can this be done? During which compilation step
> can this be done?


It is easiest to do this in an IF that knows about variables, so that
uses that require an address can be distinguished from those that
don't, and so an object can be considered as a whole. A low-level IF
like gcc's RTL that just knows about pseudo-regs and memory has too
little information left.


> I am looking for pointers to papers or other resources that describe
> this optimisation.


I read an article in the Journal of C Language Translation that dealt
with this topic (and cback) a while back, but I haven't been able to
find the issue again.


Jason
[I don't recall anything on that topic in the JCLT, but the entire table
of contents is on-line at http://jclt.iecc.com. -John]




--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.