Re: [PATCH] Fix PR32492, fallout of the removal of convert_parm_for_inlining hook

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> This makes the type verification during gimplification way more
> lax, which allows us to deal with the difference of promoted arguments
> but unpromoted argument type lists.

Seems resonable thing to do, especially the fold_convertible_p predicate
comes handy.  My VIEW_CONVERT_EXPR patch is still in testing (last
version caused couple of failures because of typo), but even with that I
guess we can just move use of fold_convertible_p into inliner and
produce either a conversion or NOP_EXPR based on it.
In fact in the patch I invented similar set of checks to avoid putting
VIEW_CONVERT_EXPRs everywhere. My checks however checked whether
VIEW_CONVERT_EXPR will have essentially the same effect as fold_convert.
So for example if user tricked float attribute and passed double, he
would get a mess with or without inlining, while with your patch the
code would work when inlined. Not sure whether from QOI point of view is
better the first or the second alternative.

(note that for cross-module inlining with --combine we need to get
inlining done at least for the case of aggregate declared in two
different units with equivalent declaration)

Honza