This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] C++ space optimization: de-cloning con/de/structors,take IV
- From: Jason Merrill <jason at redhat dot com>
- To: Stuart Hastings <stuart at apple dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 12 May 2004 14:35:26 -0400
- Subject: Re: [PATCH] C++ space optimization: de-cloning con/de/structors,take IV
- References: <email@example.com><0C52D318-A43E-11D8-B1F9-000A95A83B3C@apple.com> <27E087C8-B634-11D6-96F9-003065ED8B66@apple.com>
On Wed, 12 May 2004 10:59:00 -0700, Stuart Hastings <firstname.lastname@example.org> wrote:
> On May 12, 2004, at 10:48 AM, Jason Merrill wrote:
>> Is the version of the patch at
>> the latest revision?
> That's the last patch I offered to the FSF. The "latest-n-greatest"
> version is probably available from the apple-ppc-branch.
> Since that (ignored) patch submission, others here at Apple have fudged it
> a bit for DWARF, and it needs to be revised to use
> "tree-inline.c:estimate_num_insns()" for size computations. I had planned
> to re-offer it to FSF at some time in the indefinite future... maybe after
> WWDC (big Apple trade show, late June).
> Why do you ask?
Someone was recently complaining about the difficulty of setting a
breakpoint on a cloned constructor, which reminded me of your patch. I
apologize about failing to respond to your last submission. I really need
to come up with a better way of dealing with email; things that I don't
respond to immediately tend to get lost. In general, if I haven't
responded to a patch within a couple of days, please feel free to ping me
I'm guessing that the DWARF tweaks had to do with DECL_ABSTRACT and
DECL_ABSTRACT_ORIGIN; your patch above just clears them on the functions
themselves, leaving them set on the blocks of the function, which I would
expect to confuse dwarf2out.c. I would expect that simply adjusting
maybe_clone_body so the call to (*debug_hooks->deferred_inline_function)
is after the call to maybe_thunk_body would do the trick.
In my response to your third revision of the patch, I asked about making
the symbols both private and coalesced; obviously if we can't eliminate
duplicates that interferes with the space optimization. What's the
situation with the symbol names in the current Apple compiler? I thought
that the direction discussed at