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