Hello,
LLVM's IA-64 target has not been maintained for a few years, and it is
currently unable to compile many simple testcases. I'm planning to
remove it from the tree soon, unless someone objects.
Dan
Ouch.
The FreeBSD project is putting serious effort in getting the
OS to compile with LLVM with a future possibility to make it
the default compiler. I'm maintaining FreeBSD/ia64 and while
I was aware that the LLVM/ia64 target had bitrotted, I hoped
to find time to work on that.
I'm still interested in getting it up to par, but know that
it's also a lot of work and maintaining FreeBSD/ia64 already
eats its share of resources. As such, I'm not at all in the
position to object to the removal -- LLVM wasn't built with
(false) promises or (good) intentions.
However ... (didn't we see that coming from afar 
What I'll do right now is update, built and run tests. LLVM
built on FreeBSD/ia64 last week, so that much I know. I'll
look into the test results to see how bad it is. In the mean
time I hope that there's a way for me to put my money where
my mouth is and come to some arrangement along the lines of:
test X and Y through Z needs to pass before <event/date> or
else... *axed*
Alternatively (I don't know how bad the target is and thus
how much ramp-up time I need to get anything done), keep it
in the tree for a bit longer, but disconnect it?
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...
FYI,
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
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
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
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,
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
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 :).
You can make a 'fork' of the LLVM git mirror repo at repo.or.cz. Just
1 mouse click and you're done As a bonus - you can sync with LLVM
mainline without any problems...