On Thu, Jan 21, 2016 at 3:13 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou <ebotca...@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