On Jul 16, 2009, at 9:49 PM, Marcel Moolenaar wrote:>> For us to keep IA64 around (and for it to be minimally useful for >> your >> work!), I think that the backend should pass most of the simple >> programs in MultiSource/Benchmarks for example. It does *not* need >> to >> produce amazingly fast code, but the code needs to work. I don't >> know >> how much performance on IA64 is important to you guys, if GCC is >> currently acceptable, then probably don't have that high of a >> performance bar. > > GCC is the best we can do right now for FreeBSD/ia64. That's why LLVM > is of interest. At least to me :-)Sure. LLVM has significantly better high-level design in its code generator than GCC does, which could be the host to some really interesting itanium-specific optimizations if someone was so inclined. However, this is a *significant* amount of work, and the perf work that will benefit many other classes of machines is unlikely to be the big winners on itanium. To get decent performance, we really need people dedicated to doing significant perf work for itanium. Beyond that, we're already way way way behind GCC, so a significant amount of work would be required just to catch up with them - we don't even do real bundling, for example.> However, I do not want to go anywhere near trying to achieve optimal > code generation right now. Getting functional completeness is as high > as I dare to shoot. I presume that it'll be daunting enough.It depends a lot on your background, but yes it is a substantial amount of work.>> Another question is: who is really interested in FreeBSD/ia64? Is HP >> (for example) contributing to this work? If so, perhaps you could >> find help in one of the itanium-friendly companies. > > My Montecito machine was donated to me by a German company, but other > than that, it's just me working on an architecture I've grown fond > off.I have to admit that the architecture geek in me *really* likes Itanium, and it definitely was the "full employment guarantee for compiler engineers". :) I think it's a shame that it didn't catch on more, if only to provide more diversity in the architecture space. However, the pragmatist in me sees it as a dead architecture. Being dead in-and-of-itself doesn't mean it shouldn't have an LLVM backend: for example, I consider Alpha more-dead than Itanium :). However, maintaining an LLVM backend is a significant amount of work, and given that we've had an itanium backend since 2005 with no serious interest from developers-other-than-Duraid, I have a hard time believing that this will magically change in the near term. At this point, I think we should remove the Itanium backend from mainline. I would be thrilled if you would take it and fix it up and get it working out of tree. If you get it working on significant programs (regardless of the performance of those programs) we'd definitely accept it back in tree at that point. Does this seem reasonable to you? -Chris
On Jul 16, 2009, at 10:22 PM, Chris Lattner wrote:> >> However, I do not want to go anywhere near trying to achieve optimal >> code generation right now. Getting functional completeness is as high >> as I dare to shoot. I presume that it'll be daunting enough. > > It depends a lot on your background, but yes it is a substantial > amount of work.Low-level compiler optimizer team for Itanium at HP. I'm not on foreign soil so to speak, but there are a few reasons for me not to call it home ground. I moved out of compilers entirely and into operating systems (I seem to have a love-hate relationship with compilers -- not good for a professional carrier :-) ...> Being dead in-and-of-itself doesn't mean it shouldn't have an LLVM > backend: for example, I consider Alpha more-dead than Itanium :).\begin{sidenote} I don't consider Itanium dead. I think it had to be positioned for such a niche market (after failing miserably to be the replacement of x86 as it was first envisioned to be), that it has become mostly insignificant. \end{sidenote}> However, maintaining an LLVM backend is a significant amount of work, > and given that we've had an itanium backend since 2005 with no serious > interest from developers-other-than-Duraid, I have a hard time > believing that this will magically change in the near term.*nod* There's nothing to contradict this statement. My words are just that right now.> At this point, I think we should remove the Itanium backend from > mainline. I would be thrilled if you would take it and fix it up and > get it working out of tree. If you get it working on significant > programs (regardless of the performance of those programs) we'd > definitely accept it back in tree at that point. Does this seem > reasonable to you?It's virtually impossible to be unreasonable when it's being discussed like this. I few administrative questions come to mind. I'll ask them here, but feel free to have me take it offline: 1. Were you thinking about a LLVM (sub-)project for this, or do you want me to take it off-site? 2. If off-site: would a LLVM/ia64 project on SF.net be acceptable or do you prefer something less public (protecting the LLVM "brand" comes to mind)? I'll watch the commit logs and when I see ia64 being axed, I'll pick the latest release (2.5 right now, but maybe 2.6) and use that as the basis for the work. Cheers, -- Marcel Moolenaar xcllnt at mac.com
On Jul 17, 2009, at 9:53 AM, Marcel Moolenaar wrote:>> >> At this point, I think we should remove the Itanium backend from >> mainline. I would be thrilled if you would take it and fix it up and >> get it working out of tree. If you get it working on significant >> programs (regardless of the performance of those programs) we'd >> definitely accept it back in tree at that point. Does this seem >> reasonable to you? > > It's virtually impossible to be unreasonable when it's being > discussed like this. > > I few administrative questions come to mind. I'll ask them > here, but feel free to have me take it offline: > > 1. Were you thinking about a LLVM (sub-)project for this, or > do you want me to take it off-site?Off site would be preferable. You can hack on it in your local tree for example. I'm mostly concerned about reducing the maintenance burden of it on the main llvm project.> 2. If off-site: would a LLVM/ia64 project on SF.net be acceptable > or do you prefer something less public (protecting the LLVM > "brand" comes to mind)?I'm not worried about protecting the brand :). SF.net is a fine place to host it if you're interested in making your work public. Alternatively, you could just have a public git repo somewhere or something if git floats your boat :).> I'll watch the commit logs and when I see ia64 being axed, I'll pick > the latest release (2.5 right now, but maybe 2.6) and use that as > the basis for the work.It would probably be best to start from mainline as we are now. There have been some significant API changes from 2.5 to HEAD, and starting from current ToT would mean that you wouldn't have to handle the merge. Thanks Marcel, -Chris