http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51012
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2011-11-08 13:50:44 UTC --- On Tue, 8 Nov 2011, jamborm at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51012 > > --- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-11-08 > 13:06:29 UTC --- > (In reply to comment #2) > > > > What about WPA stage? I think we don't "fixup" inlinable status of > > edges at the beginning of ltrans (or inline transform). Do we? > > No. And unless this got addressed meanwhile, we don't need indirect > inlining to hit this bug with LTO (I belive > https://bugzilla.mozilla.org/show_bug.cgi?id=652563 is a manifestation > of this problem). IIRC, Honza had plausible reasons why un-doing > inlining decisions is tough but we eventually either need that or > store types of arguments along each call graph edge. I understand its 'though' because we possibly have thrown away the offline copy already before committing inline decisions? But - can't we simply materialize the clone? (of course that would be possibly many clones...) Note that with LTO symbol merging even direct calls may become un-inlinable (because they change to an incompatible signature). Note that the idea to _not_ inline in those cases is motivated to behave exactly the same as if we'd not inline for such undefined code. We could certainly fix this up during inlining itself - as last resort with going through a memory temporary (ugh). But we for sure will behave differently than the target machine for simple integer mode mismatches (note that what we see on gimple doesn't really reflect the target ABI or what we would see on RTL ...)
