[Bug middle-end/48674] [4.7 Regression] FAIL: g++.dg/torture/pr48661.C

hubicka at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon May 2 15:02:00 GMT 2011


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48674

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |hubicka at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-05-02 14:47:49 UTC ---
As discussed on IRC, the above patch is not really good idea.  The consequence
of it is that the cgraph edges and IPA references will point to thunk nodes.
Those are not really nodes of callgraph and a idea of graph where edge targets
are not neccesarily its nodes is slipperly.

I have patches to turn thunks to appear as function in cgraph that are somewhat
ugly, but apparently less ugly from all alternatives we was able to come with.
My original plan was to first push cleanups to callgraph, but because the whole
issue got escalated by the real world testcase, I will try to separate them
from rest of symtab code I have pending and push them to mainline soon.

The weakest point of this approach is that thunks differ from usual functions
in several ways:

1) they don't have body representable in gimple (this is the case of variadic
thunks). This require changes at places where IPA passes want to analyze
function bodies:

   a) inliner must to know how to inline thunk (or to not inline it as I do as
      a temporary hack)
   b) inline-analysis needs to special case thunk function and guess their size
   c) ipa-prop needs to compute proper jump function for THIS
   d) rest of IPA passes (pure-const/reference) are more or less trivial, 
      just need to avoid idea of looking into the function body since there 
      is nothing relevant for them anyway.

2) they don't appear as function at ABI level and must be output in chunk with
the function they are attached.
3) our RTL output machinery is somewhat convoluted.

the second two needs following changes I know of

   a) unreachable function removal must be weakened a bit on thunk functions
   b) WHOPR partitioning must know that it always have to associate thunk 
      into every partition the thunked function comes to
   c) cgraph_assemble_function 

My code bootstraps, but does not really work for i.e. Mozilla, so it is
entirely possible more side corners needs to be handled, too ;(

Honza



More information about the Gcc-bugs mailing list