> 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?
Honza
