From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9636 invoked by alias); 31 Jul 2003 00:30:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9629 invoked from network); 31 Jul 2003 00:30:28 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 31 Jul 2003 00:30:28 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h6V0UHK14987; Wed, 30 Jul 2003 20:30:17 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9) with ESMTP id h6V0UFZr020347; Wed, 30 Jul 2003 21:30:15 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9/Submit) id h6V0UAre020343; Wed, 30 Jul 2003 21:30:10 -0300 To: Gabriel Dos Reis Cc: dewar@gnat.com (Robert Dewar), gcc@gcc.gnu.org, rguenth@tat.physik.uni-tuebingen.de, s.bosscher@student.tudelft.nl Subject: Re: std::pow implementation References: <20030730134614.2C021F2DFE@nile.gnat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Thu, 31 Jul 2003 06:49:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg02274.txt.bz2 On Jul 30, 2003, Gabriel Dos Reis wrote: > Alexandre Oliva writes: > | On Jul 30, 2003, Gabriel Dos Reis wrote: > | > | > But the fact is that the compiler is not doing better by going its own > | > programmed logic. We've not reached the same level of sophistication > | > as for register allocation. > | > | And your solution for the problem is to dumb it down further such that > | it doesn't even attempt to do a good job? > I'm not proposing to dumb it further. Oh. `The compiler should do what the user tells it to (WRT inline), no more, no less.' Can you explain to me what room is left for the compiler to be intelligent (WRT inline) given this proposition? > In fact, people like you who make bogus quote of the standard to claim > that inline is implicit in C++ have already push the compiler to its > dumbest state. I'm tempted to respond with something along the lines of `people like you who refuse to accept obvious arguments claiming they're unconvincing...', but I'll get out of this discussion now, before it turns into a fight. I've already exposed my arguments, and so far your arguments have only shown that you only care about a small part of the big picture. > In effect, I'm proposing to return to first principles where the C++ > programmer is trusted, is listened to, not treated by the software > as a dumb person unable to make sensible decisions. If you're not reasonable when presented with a simple argument just because it goes against your theory, why should I expect you to be reasonable when tagging functions as inline? If you won't listen to me, why should I listen to you? Why do you insist on making claims that `old is good' while all the evidence we have is that, when using the inlining heuristics that you propose, namely, that the compiler should inline any function declared inline (explicit or implicitly, or whatever term you'd rather use to describe the fact that a member function defined inside a class body is regarded as inline), compile time *and* run time got significantly worse. The fact that you are careful about marking functions as inline only when you guess it will be profitable to inline them (and I'm assuming you do), in the scenarios in which you're using the functions, won't make it so for every C++ developer in the world, no matter how much you whine. People in different scenarios than yours, in which full knowledge about the users of classes is available and their platforms, won't be able to make as perfect a judgement WRT marking functions as to-be-inlined as you are. For people writing reusable software components, this is just not possible: they can't predict how a software component is going to be used. Of course, if you keep on convinced that the context of use of a function can't possibly affect whether it's profitable to inline the function, then the only person who will have learned anything form this debate is me, and it's that you're blinded by prejudice and/or pride. > When, the programmed logic of your inliner will reach the > sophisticated level comparable to that of automatic register > allocation, then you will have evidence to have your software not to > trust the programmer. Removing the logic we have in place that attempts to do a better job, but fails, won't help us get closer to it. If you have any concrete suggestions to improve it, please post the patches. If you don't, go at least do some research and re-discover that taking your approach to inlining has been tried with real-life C++ code, and results were disastrous. Could we do better? Sure. But it's not by wasting time on this debate that we will get there. We're just rehashing an argument that we've had at least twice in the past. Nothing new was brought in, and all you brought was a set of prejudicial personal convictions that burden programmers with decisions computers are better suited to make for them, except in very special cases. When you have facts to present that would add to the discussion, I'll be hear eager to listen to you. Meanwhile, I'll stop feeding the flame war. The only thing it has produced is heat. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer