llvm-ia64 is off the ground...

[Marcel Moolenaar]

[Combining responses...]

On Jun 10, 2011, at 8:59 AM, Roman Divacky wrote:

> On Fri, Jun 10, 2011 at 09:53:38AM -0600, Warner Losh wrote:
>> Hey Marcel,
>> 
>> I don't mean to throw cold water at your enthusiasm, but I thought I heard that upstream llvm was in the process of decommissioning ia64 support.  Did I hear wrong?
> 
> Quite :) LLVM removed their IA64 backend a long time ago (2 years?).
> Marcel is attempting to write a new one from scratch.

I was playing with LLVM at the time and was lingering on the mailing
lists when the proposal was sent. There was a short email exchange
on the subject and the end result was that I created the llvm-ia64
project on SF and LLVM removed the ia64 backend. See below for how
well the SF project faired :-)


========


> On 2011-06-10 17:38, Marcel Moolenaar wrote:
> ...
>> Unfortunately, the FreeBSD build doesn't give me goodies like
>> llc or bugpoint so there may be value in adding that to the
>> FreeBSD build as optional or developer-only build targets...

On Jun 10, 2011, at 8:58 AM, Roman Divacky wrote:

>> Unfortunately, the FreeBSD build doesn't give me goodies like
>> llc or bugpoint so there may be value in adding that to the
>> FreeBSD build as optional or developer-only build targets...
>> 
>> Thoughts anyone?
> 
> I know of a better solution :) Just build llvm libraries as shared
> and use vanilla llvm opt/llc/etc that are linked dynamically. It should
> just work.

On Jun 10, 2011, at 9:25 AM, Dimitry Andric wrote:

> These programs are of little use for normal users, or even most
> developers, except for people who hack on clang/llvm itself.

Granted.

> Also, to install them without too much overhead, we would have to start
> installing llvm and clang's shared libraries, which adds a lot of
> complexity.  Currently, we just link everything into one clang
> executable.  (There's also a tblgen executable, but it is debatable
> whether even that belongs in the base system, since it is only used for
> building llvm and clang.)

Yes, one can argue whether tblgen should be installed. I
don't think I would mind it if it wasn't installed (with
my LLVM/clang hacking hat on).

> That said, it is great you are working on this, but do you have any
> particular reason for not just using a checkout from the upstream llvm
> and clang repositories instead?  If you work inside the FreeBSD tree,
> you have a version that is slightly behind the current version, and for
> hacking on a new backend, it is usually better to get hints and advice
> from the llvm people themselves...

With the llvm-ia64 project on SF, that is exactly what I was
doing. However, I never really got it off the ground as easily
as I could do it now. The problem, I think, is that there was
an added complexity of having to deal with auto tools, the
fact that pure LLVM doesn't come with a good C/C++ frontend
and I found myself having to worry about the GCC frontend (at
the time clang was probably in the baby stage). etc...

I'm not saying it was impossible. All I'm saying that there
were more hurdles to take, more unknowns to demystify and
therefore a much steeper learning curve to overcome that it
simply wasn't as focussed an effort as I needed at the time.

Now I have a very simple goal: bootstrap a usable target for
ia64 that allows me to compile FreeBSD/ia64 correctly and have
it done before GCC is removed from the FreeBSD source tree.
As a side-effect, I hope to inspire other people to do the
same for their own favorite platform.

The build is familiar to me. No auto tools, no magic. I end up
with a single executable clang that us fully functional at
the top and even has a few fully functional targets at the
bottom.

This is not to say that I should not revisit this decisions at
a later time. I think I should. But I don't think I have to do
it before I have a working target. It's easier for me to switch
focus and worry about the LLVM development environment if I do
not have to worry about writing a backend. I'm perfectly fine
having a static LLVM source base that may only get infrequent
updates.

Anyway: in the mean time it would be great if we can bridge the
gap between LLVM/Clang in FreeBSD and having all the LLVM to
help diagnose LLVM/Clang problems. I'm good with shared libs,
additional build targets and/or having a port. I think it
helps if it's something that this mailinglist knows about and
"supports" to the extend that it can be used to describe
problems and is easy for anyone to set up.

FYI,

-- 
Marcel Moolenaar
marcel at xcllnt.net