This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [cgraph] move eh marking to except.c


On Thu, Sep 11, 2003 at 01:59:43AM +0200, Jan Hubicka wrote:
> Because in unit-at-a-time we first decide what functions needs to be
> emit and do intraprocedural optimizations based on it.  It is critical
> that we don't add new functions into the list during the later expanding
> pass.

I think its critical that we *can* handle this situation.  Even
if via fallback on "you don't get anything inlined that isn't
declared inlined".

First, I think that robustness requires this.  While we are in
transition it is virtually assured that we will miss something.
You can already see this in the objc front end, which requires
a hack in the c-obj-common code.

> cgraph_analyze_function is supposed to notice all places that
> would later result in the references.

Secondly, all cgraph_analyze_function can do is notice the 
places that *may* result in references.  If we treat the data
that we get from cgraph_analyze_function as golden then we are
going to have a QOI regression on 

	extern void bar(void (*)(void));
	static inline void baz(void) { }
	void foo(void)
	{
	  int x = 0;
	  if (x)
	    bar(baz);
	}

Until and unless we are passing these function bodies through
tree-ssa optimization passes before making our decision, we
should merely treat this data as advisory.

We should take actual use data from TREE_USED(baz) *after*
compiling foo.

Certainly we shouldn't let the advisory nature of the data stop
us from making inlining decisions.  The data we collect is a
reasonable upper bound.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]