Re: [lto][patch] Move the call to execute_all_ipa_transforms to cgraphunit.c

[Jan Hubicka <hubicka@ucw.cz>]

> 2008/11/11 Rafael Espindola <espindola@google.com>:
> 
> > So, which one is your favorite? :-) Assuming disabling the pass has no
> > regressions, should I commit that?
> 
> Yes, thanks.  Converting pass_set_nothrow_function_flag into an IPA
> pass is the right approach.  In fact, I like Jan's idea of bundling it
> with the const/pure pass.  However, that can wait.  Could you open a
> PR for it?
Well, things seems a bit more complicated here.  It seems to make sense
to do the pass both locally and at IPA level.  It probably should be
moved to gimple though.

I was just looking into inliner heuristics to make it more scalable.  On
C++ beasts like tramp3d or botan we miss a lot of early optimization
oppurtunities because we don't know if functions are const/pure/nothrow.
So I am thinking about scheduling simple local pass into early
optimizations that will look at current function body and set the flags.
(we also need alias analysis in early stages and do some function call
regularization).  Those should make early optimizers a lot more
effective and make inlining heuristics (and IPA in general) fed with a
lot less garbage.  Current trick of ignoring load/stores for program
size metrics has many sick side effects and for tramp3d we tend to
handle functions containing over 9000 loads+stores as being cheap to
inline (and indeed we optimize those 9000 statement later, but it is all
unnecesarily expensive and unsafe in a way that on different code base
where loads/stores do not optimize out we will end up inlining very
large constructors even at -Os)

We tend to simplify function bodies a lot in our late optimization
passes quite likely turning them to nothrow that in turn affect size of
dwarf2out tables quite a lot, so still doing this late nothrow discovery
seems to make sense.

So I guess ideally we should have constpure pass handling nothrow too
and having option to work either locally or doing IPA propagation and do
it on all three stages to be able to clean up the abstraction penalties
effectivly... Don't seem to be compilation time overkill here, but I
guess little experimentation will be needed.

Honza
> 
> 
> > And if it has? Should I debug the above problem?
> 
> No, it would be too much hassle for no gain.  The pass must go away.
> 
> 
> Diego.