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

[Jan Hubicka <hubicka@ucw.cz>]

> > I wonder what happens here when, say, ipa-icf redirect the call to eqivaelnt
> > function and removes the callee?  Perhaps we realy want to have set of call
> > sites rahter than nodes stored from analysis to execution. Call sites have
> > unique stmts and uids, so it will be possible to map them back and forth.
> IIUC, call site is represented using cgraph_edge ?

Yes, there is call_stmt pointer when gimple is read and uid in WPA mode which
are unique.  There is call_summary class which lets you to associate info with
a call site. While it is not most memory effecient to store one bit of information
this way, i guess it may be easiest to use it in anticipation of it becoming
more useful in foreseeable future.  We have some bits in call edge itself that
may be shuffled to the summary as well.

> So change return_callees_map to be the mapping from node to subset of
> it's call-sites where
> node returns the value of one of it's callees:
> static hash_map< cgraph_node *, vec<cgraph_edge *> *> *return_callees_map; ?

This should work too, though storing direct pointers to edges is something we
probably want to avoid to keep memory representation of edges in bounds.

I would go with call_summary - everything else seems like bit of premature
optimization.  If we will decide to optimize it later, we may invent a variant
of summary datatype for that.

Thanks,
Honza