This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/48763] Inliner type ICE


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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> 2011-04-26 13:20:24 UTC ---
> We should defer detection of incompatibilities to when we see the call stmt,
> thus expand_call_inline.  We shouldn't worry about this disturbing inliner

Undoing the inliner decisions at expand_call_inline is not trivial.

1) We would have to turn inline clone back to offline copy of the
function if one doesn't exist.
2) Doing so would resoult in duplicated offline copies of function when such
copy really exist but WPA made it static and put into a different partition.
3) With the inliner analysis being able to figure out what references and
calls will be optimized out in particular inline clone based on knowledge of
its argument, there is no way to output those references (they might refer
things not exported from different WPA partitions).
So the offline clone would have to be clone with the constants figured out by
the inliner propagated in.

I am not sure if those are all problems, but I guess we can go this way,
but it is remarkably ugly.

Also we need smilar kind of validation for ipa-prop.  Jump functions will
get confused on calls with mismatching types. This would mean that the constant
propagation trick above might fail making things even more messy (ie.
propagating
constant into a structure argument or so).

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]