This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] C++ space optimization: de-cloning con/de/structors, take IV

On May 12, 2004, at 11:35 AM, Jason Merrill wrote:

On Wed, 12 May 2004 10:59:00 -0700, Stuart Hastings <> 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
about it.

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.

Thank-you for this suggestion; I'll see what Devang (I think it was Devang) did, and try to make sense of it all.

Given the evident interest, I will craft a patch against the current FSF TOT and offer it for discussion.

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

seemed reasonable.

I inquired with Matt Austern (in the adjacent office :-), and was told that nothing had been proposed to the ABI committee.

stuart hastings
Apple Computer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]