From owner-freebsd-ia64@FreeBSD.ORG Tue Nov 10 21:19:19 2009 Return-Path: Delivered-To: ia64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF9CB1065670 for ; Tue, 10 Nov 2009 21:19:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id D8E1D8FC1B for ; Tue, 10 Nov 2009 21:19:19 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KSW00BZLWK4QN40@asmtp025.mac.com> for ia64@freebsd.org; Tue, 10 Nov 2009 13:19:17 -0800 (PST) From: Marcel Moolenaar In-reply-to: <87hbt5yg9i.wl%peter@chubb.wattle.id.au> Date: Tue, 10 Nov 2009 13:19:16 -0800 Content-transfer-encoding: quoted-printable Message-id: <53C58109-BD6C-4314-B498-D628023CF553@mac.com> References: <595329F2-46F2-4393-B8E3-0923694D250D@mac.com> <20091107214031.GB78634@mech-cluster241.men.bris.ac.uk> <4AF5F413.7010302@osunix.org> <20091107232251.GA33482@mech-cluster241.men.bris.ac.uk> <87hbt5yg9i.wl%peter@chubb.wattle.id.au> To: ia64@freebsd.org X-Mailer: Apple Mail (2.1077) Cc: Michael Dexter Subject: Re: 2009 Update X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 21:19:20 -0000 [combined response] On Nov 7, 2009, at 5:08 PM, Peter Chubb wrote: > Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is > miles better than gcc 3.x -- but there's still a lot that could be = done > with low-level instruction scheduling. My immediate concern is correctness. Improving SPECcpu20xx looks good academically, but means nothing to me in the context of FreeBSD if it means spending a lot time finding work-arounds for correctness bugs. At this time we can't compile the kernel correctly when all debugging options are removed and I think we actually have a more optimal OS with a compiler that generates less-optimal, but correct code than what we now have with GCC 4.2.1. I find that bizarre.. I would probably stick with GCC much more longer if it would at least generate correct code. Nonetheless, any future improvements that people may make, may not be usable by FreeBSD due to licensing anyway, so to me it's not as simple as "just fix what's broken"... On Nov 7, 2009, at 9:16 PM, C. Bergstr=F6m wrote: > Small notes.. > a) PathScale doesn't currently support IA64 Another aspect, again specifically in the context of FreeBSD, is that architecture support in PathScale (or Open64) is limited. As such, it won't easily be the next system compiler. At this time LLVM has the best chance of replacing GCC, if GCC is ever being replaced. Alas, the LLVM project recently removed the ia64 backend due to lack of support. Just my luck :-) While PathScale (and Open64) are great compilers for in the ports collection and I would be very happy to see that happen, I do need to keep an eye out for any developments involving the system compiler and I may be forced to work on that just to keep FreeBSD on ia64 viable without forking off... > b) I would like to merge in some code that would give us a near = optimal CG for IA64. That in combination with a couple other things = would hopefully bring us in the same ballpark as the Intel IA64 = compiler. (Pure speculation as I don't know this target very well or = current state of Intel compiler) Speculation is the correct word: the Intel compiler utilizes data and control speculation and achieves good results in certain cases because of it. The use of explicit prefetch operations also helps to prime the cache with good results. The CG for Itanium in PathScale should utilize this as well to be in the same ballpark as the Intel compiler. At least, that's what I assume it should do. If the code comes from Open64, then I think you'll be in the same ballpark. People (including Intel as part of the ORC project) have done a great job. On Nov 7, 2009, at 10:43 PM, Peter Chubb wrote: > The reason we put so much effort into attempting to improve things is > that most people will just try to run their code with the compiler(s) > they already know. I can see that. Then again, I also fail to see it. With autoconf and libtool, compiler differences should be non-issues and the only thing developers should do is actually write portable code. I believe that there's an even deeper and darker consequence to the statement that people just try with the compiler they already know and that is that the assumptions embedded in the code about the architecture are not expected to cause problems. Itanium did cause a lot of code churn while porting code from i386 to ia64 and it wasn't just for being 64-bit. Still a lot of code uses 'int' for variables that are never negative when 'unsigned int' yields more optimal code simply because it avoids an unnecessary sign-extension. What I'm trying to say is that assumptions about the compiler are just a part of the problem and it's probably a smaller problem than assumptions embedded in the code that cause unique problems on Itanium. Assumptions about the architecture may have a bigger impact on the resulting performance than assumptions about the compiler will have. It's good to keep as much the same if so many things change, so Gelato's work has been good and beneficial. I was more in touch when I worked @HP then I am now, so I don't know all the good Gelato has done. --=20 Marcel Moolenaar xcllnt@mac.com