The MBlaze backend: can we remove it?

The MBlaze backend seems to be essentially unmaintained since 2011. The maintainer (Wesley Peck who is BCC’ed) seems to have vanished, and in fact all emails to him are bouncing.

I propose to remove the MBlaze backend on Friday if none step forward as a maintainer. Currently, folks are having to keep it up to date when changing shared parts of the backend with no help.

-Chandler

Hi Chandler,

This seems entirely reasonable.

Thanks,
  Jim

+1

I just want to clarify: there is no actual problem with the MBlaze backend,
and this isn't a trap. ;] It's a really nice backend, the code quality is
fine, we just need an active maintainer to help fix issues and keep it up
to date as the code generator layer evolves. =] Hopefully someone is
interested in getting involved in the community here and contributing to
the backend.

I think you should wait until it becomes a problem.

Xilink is actively hiring for LLVM people so maybe it will get some use again soon. I get at least one email a day from their head hunters.

http://en.wikipedia.org/wiki/MicroBlaze

I think you should wait until it becomes a problem.

Spending maintenance time, build time and test time on a project no
one needs *is* a problem.

Xilink is actively hiring for LLVM people so maybe it will get some use
again soon. I get at least one email a day from their head hunters.

http://en.wikipedia.org/wiki/MicroBlaze

Chandler proposed to wait a few days. If Xilinx cares enough they
should step up saying that they care about this backend and they are
going to maintain it.

Eli

I think you should wait until it becomes a problem.

When I said it is not a problem, I meant there is no burning, systemic
problem with the backend as there have been in other backends.

However, we are burning plenty of time of engineers supporting it for every
change to the common code generator. Also, we have known bugs in the code
and the backend, and no one to really report them to. This doesn't seem
like a healthy state for a backend to be in, and it also doesn't seem like
a new state. (again, I've not seen any real activity here in all of 2012...)

Hi i have a new customer who needs it. I’m interested in maintaining it myself.

I need to step up quickly though because i haven’t even looked at the backend since 2011.

Hi Rogelio,

  Glad to see MBlaze will not be removed. I suggest you put your name on
CODE_OWNERS.TXT. :wink:

Regards,
chenwj

I think instead, it would be more appropriate to start working through
issues, cleaning up code, and other patches before adding to a text file.
We need active maintainers working on backends that they care about, not
just entries in a file. =]

I'm working on it now.

Is it advisable to use git exclusively? svn seems to fail to build on
hardened systems. the compiler needs to build and run on grsec/pax.

Rogelio,

Is it advisable to use git exclusively? svn seems to fail to build on
hardened systems. the compiler needs to build and run on grsec/pax.

can't you use git-svn? Or even that part fails to build?

Hi,

I just saw this thread. I work on llvm at Xilinx but I do not work on microblaze.

I will check to see if there is any interest here at Xilinx to contribute resources to the maintenance of this backend.

Thanks,
Jeff

Thanks, Jeff!

-Jim

Hi jeff! Any news?

Hi Rogelio-

Internally I have found some interest but no official Xilinx commitment of manpower. That said, I’m willing and able to volunteer a bit of my time. I see the MBlaze port as potentially valuable for my own projects and I found it useful as an example when porting llvm to a new architecture. Do you have a collection of open issues you are working through? I’ll start by building myself a microblaze system and trying to set it up so that I can run llvm tests.

Thanks,
Jeff

Chandler Carruth <chandlerc <at> gmail.com> writes:

The MBlaze backend seems to be essentially unmaintained since 2011. The

maintainer (Wesley Peck who is BCC'ed) seems to have vanished, and in fact
all emails to him are bouncing.

I propose to remove the MBlaze backend on Friday if none step forward as

a maintainer. Currently, folks are having to keep it up to date when
changing shared parts of the backend with no help.

Dear Mr Carruth,

I am Fernando Herrera. I work for the University of Cantabria (Spain).
We are interested in the microblaze branch of LLVM (preferently
as users).

Do you know if there is any available (even if unofficial
or out of the tree) branch which could work with LLVM 3.5 (or later)?

Maybe somebody in Xilinx?

Eventually, we could update it to make it work with
later LLVM versions, as long as we can afford that cost.

Many thanks in advance for any information you can give to us.

Best

Fernando

[snip]

Dear Mr Carruth,

I am Fernando Herrera. I work for the University of Cantabria (Spain).
We are interested in the microblaze branch of LLVM (preferently
as users).

Do you know if there is any available (even if unofficial
or out of the tree) branch which could work with LLVM 3.5 (or later)?

Maybe somebody in Xilinx?

Eventually, we could update it to make it work with
later LLVM versions, as long as we can afford that cost.

Many thanks in advance for any information you can give to us.

Best

Fernando

Hi Fernando,

I've been pseudo-maintaining the Microblaze code generator since it was removed. It does compile, with recent TOT LLVM (last update was to LLVM r247783),
Unfortunately, over time it has stopped being fully working, even for C (C++ needs some atomic work as I recall). I suspect getting it functional again wouldn't be too hard, I just haven't had time.

I tried to get someone at Xilinx interested in it, since maintaining it, even to just keep compiling, takes a bit of time. They didn't seem to be interested, and the only reason I've been keeping it up is that I seem to have a stubborn streak.

If you're interested, the code is at http://ellcc.org.

Best regards,

Rich

[snip]

Dear Mr Carruth,

Dear Richard

I am Fernando Herrera. I work for the University of Cantabria (Spain).
We are interested in the microblaze branch of LLVM (preferently
as users).

Do you know if there is any available (even if unofficial
or out of the tree) branch which could work with LLVM 3.5 (or later)?

Maybe somebody in Xilinx?

Eventually, we could update it to make it work with
later LLVM versions, as long as we can afford that cost.

Many thanks in advance for any information you can give to us.

Best

Fernando

Hi Fernando,

First of all, Thanks a lot for your answer!

I've been pseudo-maintaining the Microblaze code generator since it was
removed. It does compile, with recent TOT LLVM (last update was to LLVM
r247783),

OK. I think it is worth for us to try it and likely sufficient for our
research purposes if it can deal with our use cases and if the performance
compared to thet gcc-based port is comparable.

Unfortunately, over time it has stopped being fully working, even for C
(C++ needs some atomic work as I recall). I suspect getting it
functional again wouldn't be too hard, I just haven't had time.

OK. In other words, "forget about C++" and "do not expect C
fully working, but getting it could be feasible for you", right?
In the latter case, I guess that some LLVM expertise is required.
What could we expect for getting it, days, weeks, months (assuming full
time)?

I tried to get someone at Xilinx interested in it, since maintaining it,
even to just keep compiling, takes a bit of time. They didn't seem to be
interested, and the only reason I've been keeping it up is that I seem
to have a stubborn streak.

:slight_smile: maybe fortunately. It would be interesting to know their points.
In my view, it could be something very interesting for Xilinx, as long,
to my understanding, LLVM is becoming a kind of reference compiler for
research community, specially because it allows at some extend to
know about & control compiler behaviour. This, together the configurability
and controllability which provides FPGA at HW level, gives
a very competitive technology for controlling the whole SW/HW tool chain.
So, for instance, this can be very useful in the development of
embedded applications with hard real-time constraints.

If you're interested, the code is at http://ellcc.org.

OK. We will look into it.

Thanks a lot again for the info.

Best!

Fernando