Re: Tree inlining for the C front end (part 3 of 3)

[Daniel Berlin <dan at cgsoftware dot com>]

On Tuesday, September 25, 2001, at 05:07  AM, Alexandre Oliva wrote:

> On Sep 25, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
>
>> We really, really, really should avoid having a huge regression in
>> these respects as we had for the C++ frontend in GCC 3.0 and 3.0.1.
>
> I doubt it would affect C as much as it did C++.  The absence of
> implicit inline in C, as is the case for member functions defined
> inside a class body in C++, will most definitely make a huge
> difference for C.
Prove it. No offense or anything.

>
> Anyway, I don't think imposing such requirements on me is fair.
Nothing personal, but i think it's completely fair.
Not doing performance testing on patches specifically meant to improve 
performance (Otherwise, why the heck are we doing tree inlining at all?) 
is how we end up with things like a completely broken store motion.
Had performance testing been done, it would have been noticed that it 
made 0% difference.
It would  be one thing if we didn't have people generally willing to do 
SPEC benchmarks *for* you, if you ask, but we do.

>  I'm
> not introducing the tree inlining infrastructure, I'm just adopting
> for C what's already in place for C++.  So, if you're so much
> concerned about the problems that were introduced with tree inlining
> in C++, you might as well push for disabling tree inlining in C++.

Maybe you missed that it *was* pushed for a few months back. Check the 
message archives. I think Mark said it was too difficult (which I found 
odd, but he knows the C++ front end more than me), or something of the 
sort.

>  I
> find it a far more saner approach to put the change in, and then keep
> on working to improve the tree inlining infrastructure and
> heuristics.
I don't.
Why introduce a problem that doesn't currently exist?
We *know* there are likely to be performance issues, we *already* have 
them. Why should we not be careful to try not to add another?
Is it really that much to ask in this case to do performance 
benchmarking to make sure it doesn't happen?
I'm not trying to say that this patch *must* produce a performance 
increase, i'm saying we should make sure it doesn't screw our 
performance.

>  Not enabling it for C will just let the problem hidden
> for longer.
>
No, it will just stop the problem before it occurs, or show us it won't 
occur.