From -8510146538036423991 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 21 Dec 2005 02:10:05 -0600 Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Newsgroups: comp.std.c++ From: "Andrei Alexandrescu (See Website For Email)" Subject: Re: Is this really unspecified behavior? Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.7.2.0 Content-Transfer-Encoding: 7bit Organization: Computer Science & Engineering, U of Washington, Seattle Message-ID: References: <1132759176.368850.264850@g43g2000cwa.googlegroups.com> <1132933832.802917.153350@g14g2000cwa.googlegroups.com> <1133551647.532929.325730@z14g2000cwz.googlegroups.com> <1133583412.951239.208510@g49g2000cwa.googlegroups.com> <1133910546.716987.80030@g14g2000cwa.googlegroups.com> <0l5ep1ppfhdj5p1pcu7e4na4ub0vjajlq3@4ax.com> <87i Mime-Version: 1.0 X-Nntp-Posting-Host: parakeet.ee.washington.edu Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Wed, 21 Dec 2005 02:07:04 CST Lines: 79 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-1vFcH/NVlmPinO3ZxjtK/Ptj8WyaXfclTJ9TlmuJtIw3kygkS4IZjaXSvzeszRXy5fto7yqtcJhVIel!Ktw8YxgZLIKGyXujXwulSHiJQ7UZPujjkO+MLWlOCubzPMQXrpltNsnLxSARmB8z97rc+XFLEQDd!hjZ8hIOMCqC1IkeYSCjY X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:2873 David Abrahams wrote: >>This hypothetical high-performance code and smart/stupid compiler is >>a myth anyway, but people confused by order of evaluation issues are >>all too real, ... > > > Okay, maybe I'm one of them, and you can clear it up. Andrew Koenig > described why evaluation order might matter to a compiler > (http://groups.google.com/group/comp.std.c++/msg/54716a09f97cc000). > Do you have an argument against his post? Executing the expression that takes most register first is better if the other expression leaves a lot of live registers (registers that will be read later). In the case of evaluating a function's arguments, there are no live registers remaining after pushing the result on the stack, so I'm unclear on why the technique would be desirable or more efficient. > Also, it seems obvious to me that in some cases at least, evaluating > the arguments in the same order they need to be pushed onto the stack > could be important: > > g( f1(), f2(), f3() ) > > call f3 > push r0 > call f2 > push r0 > call f1 > push r0 > call g > > If you force an ordering that conflicts with the calling convention, > you end up with > > sub sp, #3 > call f1 > mv r0, sp+1 > call f2 > mv r0, sp+2 > call f3 > mv r0, sp+3 > call g > > What am I missing? The fact that that code passes through a ton of optimizing transformations before it's ever executed? At the macro level, see for example http://64.233.167.104/search?q=cache:fDzJHL3l3ccJ:www.codeproject.com/cpp/calling_conventions_demystified.asp+intel+fastest+calling+convention&hl=en I quote: "How fast is this calling convention, comparing to __cdecl and __stdcall? Find out for yourselves. Set the compiler option /Gr, and compare the execution time. I didn't find __fastcall to be any faster than other calling conventons, but you may come to different conclusions." (N.B. _fastcall places vars in registers, __cdecl puts them on the stack RTL and has the caller clean the stack up, __stdcall puts them on the stack RTL and has the callee clean the stack up.) > Arguments about how the compiler can reorder code at will when it can > detect that the order doesn't matter don't carry a lot of weight with > me, since the compiler can't know anything about what happens behind > the scenes of a non-inlined function (without whole program analysis > of course). If the functions aren't inlined, the compiler can not decide whether there's any gain from calling them in one sequence or another, so sticking with left-to-right would be as sensible as anything else. Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]