This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Tree inlining for the C front end (part 3 of 3)
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: Tree inlining for the C front end (part 3 of 3)
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Tue, 25 Sep 2001 07:56:58 -0400
- Cc: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, <gcc-patches at gcc dot gnu dot org>
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.