Re: [RFC] propagate malloc attribute in ipa-pure-const pass

[Jan Hubicka <hubicka@ucw.cz>]

Prathamesh
> > OK, thanks!
> Thanks, committed as r254140 after following validation:
> 1] Bootstrap+test with --enable-languages=all,ada,go on
> x86_64-unknown-linux-gnu and ppc64le-linux-gnu.
> 2] LTO bootstrap+test on x86_64-unknown-linux-gnu and ppc64le-linux-gnu
> 3] Cross tested on arm*-*-* and aarch64*-*-*.
> 
> Would it be a good idea to extend ipa-pure-const to propagate
> alloc_size/alloc_align and returns_nonnull attributes ?
> Which other attributes would be useful to propagate in ipa-pure-const ?

Good I did not discourage you by slow review rate (will try to do something
about it).
I guess alloc_size/alloc_align are obvious candidates.

returns_nonnull is a special case of VRP over returns so I would rather
like to see ipa-prop/ipa-cp extended to handle return values and this done
as a consequence.

One interesting case I think we could try to track is what types of exceptions
are thrown.  Currently if function throws specific exception which is handled
by caller, we still think caller may throw because we do not take types into
consideration at all.  I think that may mark significant portion of functions
nothrow as this seems like common coding practice.

It would be also nice to cleanup ipa-pure-const.  I think one can implement
propagation template where one just feeds the basic parameters (what data
to store, what edges to consider) rahter than copying the rather outdated
code again and again.
> 
> Also, I would be grateful for suggestions on how to propagate malloc
> attribute through indirect calls.
> Currently, I have left it as FIXME, and simply drop the lattice to
> MALLOC_BOTTOM if there's an indirect call :(
> 
> I am not able to understand how attribute propagation across indirect
> calls works.
> For example consider propagation of nothrow attribute in following test-case:
> 
> __attribute__((noinline, noclone, nothrow))
> int f1(int k) { return k; }
> 
> __attribute__((noinline, noclone))
> static int foo(int (*p)(int))
> {
>   return p(10);
> }
> 
> __attribute__((noinline, noclone))
> int bar(void)
> {
>   return foo(f1);
> }
> 
> Shouldn't foo and bar be also marked as nothrow ?
> Since foo indirectly calls f1 which is nothrow and bar only calls foo ?

Well, foo may have other uses where it calls something else than f1
so one needs to track "nothrow in the context when f1 is called".

In general I think this reduces to may edges in the callgraph (for given
indirect calls we want to track whether we know complete list of possible
targets).  We do that for polymorphic calls via ipa-polymorphic-call analysis
but I did not get around implementing anything for indirect calls.

To ge the list of targets, you call possible_polymorphic_call_targets which
also tells you whether the list is complete (final flag) or whether there may
be some callees invisible to compiler (such as derrivate types from other
compilation unit).

The lists may be large and for that reason there is cache token which tells
you if you see same list again.

Extending ipa-pure-const to work across final lists of polymorphic targets
may be first step to handle indirect calls in general.

Honza
> 
> The local-pure-const2 dump shows function is locally throwing  for
> "foo" and "bar", and ipa-pure-const dump doesn't appear to show foo and bar
> marked as nothrow.
> 
> Thanks,
> Prathamesh
> > Honza