This is the mail archive of the gcc-patches@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]

Re: [PATCH][RFC] Another approach to fixing "bad" inlining


Richard Guenther <rguenther@suse.de> writes:

> This reverts (parts of) the earlier patch that got rid of the
> langhook convert_parm_for_inlining.  With this patch we no longer try
> to avoid inlining functions with mismatched parameters, instead we
> try to deal with it after the fact (the same we did with the langhook,
> but instead of relying on the frontend to define convertibleness we
> use the new fold_convertible predicate and instead of issuing an
> error if conversion is not possible we simply leave the parameters
> or return variables uninitialized).
> 
> Instead of leaving things uninitialized we could also emit
> VIEW_CONVERT_EXPRs and hope for the best (that rtl expansion won't
> ICE on us, or that by luck we make more code "work" even if it is
> undefined).
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> Of course we again don't have many testcases that exercise these
> code paths, but this approach looks saner than the previous one.
> Still, there may be better suggestions?
> 
> (the interesting parts of the patch are in tree-inline.c)

The whole patch looks reasonable, but you lost me somewhere, probably
because I've forgotten the earlier thread.  How can you call a
function, inline or not, if you can't convert the argument type to the
parameter type?  Are you just handling an error case here?  Should we
give an error instead of setting rhs to NULL_TREE, or will one already
have been given?  What is an example of code whose behaviour will
change after your patch?

Ian


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