Ian, Richard, Diego --
I've explicitly forwarded this to you, as folks who have done work on
middle-end optimization and have seen lots of real-world code.
(That's not to say that I'm not looking for comments from anyone and
everyone -- but I'm specifically trying to get at least some feedback,
so I'm picking on some likely candidates. :-))
Do you have any thoughts on the comments quoted below? Does it seem
overly aggressive to you to assume "f" cannot throw in "g", given:
void f() {}
void g() { f(); }
where this code is in a shared library? Of course, with DWARF2 EH, the
cost is mostly in terms of code size; whereas with SJLJ EH it's also
execution time. Is it silly for me to be worrying about this
pessimization in 4.1.2?
Thanks,
>> 2. g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC.
>
> This appears to be another manifestation of the problem from PR 29487
> (now fixed). Here, the compiler is again making an unreasonably
> conservative assumption that will substantially penalize C++ shared
> libraries: namely, that all global functions in shared libraries may be
> replaced at link time, and that callers must therefore assume that they
> may throw exceptions.
>
> You are correct that this stems from Richard's patch, though that patch
> made sense on its own: he used the same rules for exceptions that were
> otherwise used for const/pure functions.
>
> I think the key flaw here is that we are using binds_local_p in two
> different ways. One way is to tell us what kind of references we can
> emit; for a locally bound entity we may/must use certain relocations,
> etc., that we cannot with a global entity. However, I think it's
> unreasonably pessimistic to say that just because the user might use the
> linker to replace a function in some way, we can't reason from the
> function's behavior. If the user doesn't state that intent explicitly
> (by declaring the function weak), I think we should be free to optimize
> based on the body of the function.
>
> I think that this suggests that even the definition of
> DECL_REPLACEABLE_P that I checked in is too conservative. Perhaps the
> definition should simply be "DECL_WEAK (decl) && !DECL_COMDAT (decl))";
> in other words, only explicitly weak functions are replaceable from an
> optimization point of view. It was weak functions that were the
> motivation for the original change.
>
> I would certainly appreciate comments from others about this issue.
>
> I do think this is an important issue; it would be bad for Mozilla, KDE,
> etc., to suffer a significant optimization issue in going from 4.1.1 to
> 4.1.2. I was pretty determined to get 4.1.2 out the door, and I really
> don't want to have any functional changes between the last RC and the
> actual release. So, I feel that I have no choice but to do a 4.1.2 RC3
> with a more conservative version of DECL_REPLACEABLE_P.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
