> I'm committing the following test case that displays the bug. It does > in fact pass with mainline, and does in fact fail with gcc 4.4.0. > > I spent two days trying to come up with some cleaner way to fix this bug > than the inlinable flag you pass around, but to no avail. The only > thing better I could think of is some global flag (or state variable) > that indicates whether or not inlining is complete. At least then we > would not have to pass around that flag. But I wouldn't want to > introduce yet another boolean state variable; I'd much prefer all of the > existing state variables we have be consolidated, and I can't justify > spending the time on that just now.
There is cfun->after_inlinng that says you this info on per-function basis. I will run the tests on C++ benchmarks this weekend whether simply assuming all calls to be possibly inlined throws before this flag is set is producing noticeable degradation in memuse/compile time. Honza > > >Well, we can either teach inlinable_call_p to handle your new indirect > >calls as "for sure uninlinable" > > This is the approach I'll take. I've already hacked on an extra bit in > the gimple call subcode to indicate whether an indirect call is nothrow; > I might as well add another bit to say an indirect call is noinline. Yep, it seems sort of resonable too. Honza
