Do not produce empty try-finally statements
Jan Hubicka
hubicka@ucw.cz
Tue Jan 28 17:38:00 GMT 2014
> Hi,
>
> On Tue, 28 Jan 2014, Richard Biener wrote:
>
> > >> The EH optimizations involving cleanups with only clobbers in them
> > >> are that if at the end of the cleanup after only CLOBBER stmts you
> > >> would rethrow the exception externally, then the clobber isn't needed
> > >> and the whole cleanup can be removed. And, if it rethrows somewhere
> > >> internally, we can move the clobber stmts to the landing pad of
> > >> wherever it would be caught.
> > >
> > > OK, I still do not see how ehclanup1 can then safely remove them
> > > pre-inline given that the whole function body can be inlined into
> > > another containing the outer EH region.
> >
> > That's true.
>
> Yes, and I think they should be removed only after inlining.
In that case I think I shoud look into detecting clobber only EH in inliner and
do not account it into the size/time estimates. I always wondered why tramp3d
becomes so harder for inliner with EH enabled, I seem to get it now ;)
> (Alternatively the inliner could be extended to add clobbers when changing
> an external-throw into an internal-throw, but well, ...)
>
> > > If this is valid, why we can not just eliminate EH in those outer
> > > clobber try..finally as part of ehlowering earlier?
> >
> > Probably we'd miss too many inlining cases from early inlining and the
> > ehcleanup1 time is just a heuristic that works good enough for us?
>
> No, removing even more clobbers would remove even more stack slot sharing.
> If anything we should remove _less_ regions (as in the precondition for
> Honzas sentence above, "If this is valid, ..." simply is false). AFAIU
> this all is just a problem with O0 code quality. So, there's the obvious
> solution: run ehcleanup also for O0.
It is also problem of inliner quality decisions and memory use/compile time.
The in-memory representation of unnecesary EH is quite big.
I am quite ignorant in this area, but for -O0 can't we simply disable all
clobbers?
Honza
>
>
> Ciao,
> Michael.
More information about the Gcc-patches
mailing list