GCC 4.1.2 RC2

[Mark Mitchell]

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
mark@codesourcery.com
(650) 331-3385 x713