Re: [patch] Restore cross-language inlining into Ada

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Jan 21, 2016 at 3:13 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> > Hi,
>> >
>> > this patch from Jan:
>> >   https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01388.html
>> > totally disabled cross-language inlining into Ada without notice, by adding a
>> > check that always fails when the language of the callee is not Ada...
>> > The attached patch simply deletes this new check to restore the initial state.
>
> I only updated
> -  /* Don't inline if the callee can throw non-call exceptions but the
> -     caller cannot.
> -     FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
> -     Move the flag into cgraph node or mirror it in the inline summary.  */
> -  else if (callee_fun && callee_fun->can_throw_non_call_exceptions
> -          && !(caller_fun && caller_fun->can_throw_non_call_exceptions))
> -    {
> -      e->inline_failed = CIF_NON_CALL_EXCEPTIONS;
> -      inlinable = false;
> -    }
> to actually work with LTO where callee_fun/caller_fun is not always available
> (but sometimes, like when ICF requested the body or when we merged profiles, it
> is).
>
>> >
>> > Tested on x86_64-suse-linux, OK for the mainline?
>>
>> I think the intent was to allow inlining a non-throwing -fnon-call-exceptions
>> function into a not -fnon-call-exceptions function but _not_ a
>> non-throwing not -fnon-call-exceptions function (that "not-throwing" is
>> basically a non-sensible test) into a -fnon-call-exceptions function
>> because that may now miss EH edges.
>>
>> So the test looks conservatively correct to me - we can't reliably
>> check whether the callee throws if the IL now were -fnon-call-exceptions
>> (which we know the caller is after !opt_for_fn (callee->decl,
>> flag_non_call_exceptions)
>>
>> So - this doesn't look correct to me.
>>
>> OTOH
>>
>> static inline int foo (int a, int *b)
>> {
>>   return a / *b;
>> }
>>
>> int __attribute__((optimize("non-call-exceptions")))
>> bar (int *p, int *b)
>> {
>>   try
>>     {
>>       return foo (*p, b);
>>     }
>>   catch (...)
>>     {
>>       return 0;
>>     }
>> }
>>
>> happily inlines foo with your patch but doesn't ICE during stmt verification.
>>
>> So maybe we're not verifying that "correctness" part - ah, yeah, I think
>> we changed it to only verify EH tree vs. stmt consistency but not the
>> other way around.
>
> Well, it is a while since I looked deeper into EH code, but if I remember
> correctly we have EH region associated with statements and the non-call
> exceptions do not have EH region that is taken by EH code as an information
> that the statement was proved to not throw? In that case inlining could be
> safe, if the inlined statements are not placed in EH region (I think inliner
> does that)
>
> So perhaps this inlining is always safe?

That's what I think.

Richard.

> Honza