[llvm-commits] [llvm-gcc-4.2] r53130 - /llvm-gcc-4.2/trunk/gcc/cgraphunit.c
Chris Lattner
sabre at nondot.org
Sat Jul 5 10:02:51 PDT 2008
On Jul 4, 2008, at 11:46 AM, Eric Christopher wrote:
>>>>>
>>
>> If debug_foo is dead, and there are no objects of type foo or foo*
>> (either of which would cause the type to be emitted), why would you
>> want to do this?
>
> As I said, for debugging purposes, i.e. within gdb calling the
> function.
> Think debug_tree from gcc.
>
>>>> Make the function non-static. Note that this only changes behavior
>>>> when compiling C++, not C. In C++ the same thing already happens
>>>> for
>>>> inline functions and many other cases.
>>
>> This won't work when LTO is on, will it? You need the explicit
>> "used" (actually, I'm not sure whether LTO honors that, but it ought
>> to).
>
> Well, hopefully people aren't using LTO with O0. That'd just be a
> little weird. :)
Eric, this is only a change for C++ and it is a change back to the
previous behavior. C++ also "suffers" from inline functions not being
being emitted if not used, so it seems reasonable for static functions
to behave the same way. This obviously follows some user's
expectations.
The reason this matters is that real libstdc++ headers have static
functions and they obviously don't expect them to be emitted (they
really are not debugging hooks). Emitting them really does bloat
executables and significantly slow down the compiler (extra codegen +
tons of extra debug info), so this really does impact real users.
Emitted dead functions on the basis that they might be debug hooks is
a theoretical benefit to theoretical users who have a better solution
to their problem anyway.
Pragmatically, I strongly believe that we should not emit them: there
are many workarounds for real debugging hooks, and developers who have
ever used or cared about G++ 4.0 are already using them. Finally, why
should we try to emit debugging hooks at -O0 only? We do care about
debugging at higher levels even though the experience is admittedly
(far) from perfect there.
-Chris
More information about the llvm-commits
mailing list