On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote:> > BTW: I don't run Linux at all, so no Linux/ia64 support. > I can see how that could be a problem for people. > > Anyway: my case is a weak one and I would understand if the > target get axed without considering my email/request...Hi Marcel, There are two levels of problems with the IA64 backend. On the first level, it has not been maintained for a long time, and isn't able to compile hello world to a working app. This is a pretty bad state. On the second level, it will take a significant amount of work to make it produce code that is actually *fast* for itanium, because of the advanced architectural features of the chip. 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. 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. -Chris
On Jul 16, 2009, at 5:51 PM, Chris Lattner wrote:> > On Jul 16, 2009, at 2:30 PM, Marcel Moolenaar wrote: > >> >> BTW: I don't run Linux at all, so no Linux/ia64 support. >> I can see how that could be a problem for people. >> >> Anyway: my case is a weak one and I would understand if the >> target get axed without considering my email/request... > > Hi Marcel, > > There are two levels of problems with the IA64 backend. On the first > level, it has not been maintained for a long time, and isn't able to > compile hello world to a working app. This is a pretty bad state. On > the second level, it will take a significant amount of work to make it > produce code that is actually *fast* for itanium, because of the > advanced architectural features of the chip.*nod*> 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 :-) 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.> 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. As for help: I don't think there's any interest among Itanium-friendly companies, unless there's a company that has a vested interest in LLVM. HP and Intel have their own compilers and if they work on some open source compiler, it's either GCC or ORC/Open64 AFAICT. I actually expect more help from LLVM-friendly companies -- if only with suggestions, feedback and review comments :-) -- Marcel Moolenaar xcllnt at mac.com
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