Hi all,
We would like to contribute a new backend for the Lanai processor (derived from the processor described in [1]).
Lanai is a simple in-order 32-bit processor with:
- 32 32-bit registers, including:
- 2 registers with fixed values;
- 4 used for program state tracking (PC, SP, FP, RCA);
- 2 reserved for explicit usage by user (R10 and R11), used in threading library;
- Up to 4 used for argument passing;
- No callee-saved registers
- No floating point support
Backend development is focused primarily on compiling C99 code (no exception support). The patches implement all the parts required for code generation:
We are still actively developing the backend and have many optimizations in mind.
I’ll be the maintainer of this backend.
Please leave code comments on the Phab patches, while discussing high-level comments about the backend on this llvm-dev thread.
Thanks,
Jacques
[1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. Parallel Computer Architecture: A Hardware/Software Approach (1st ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.
From: "Jacques Pienaar via llvm-dev" <llvm-dev@lists.llvm.org>
To: llvm-dev@lists.llvm.org
Sent: Tuesday, February 9, 2016 11:40:21 AM
Subject: [llvm-dev] [RFC] Lanai backend
Hi all,
Hi Jacques,
We would like to contribute a new backend for the Lanai processor
I suppose I can guess from your e-mail address who "we" are?
(derived from the processor described in [1]).
Lanai is a simple in-order 32-bit processor with:
Can you say a few words about what this is, in what hardware it appears, and how it can be used? Is this the Myricom processor? What version(s)? Aside from the Clang/LLVM support, what other software, drivers, etc. would be needed to make use of this support? What versions of that software?
-Hal
From: “Jacques Pienaar via llvm-dev” <llvm-dev@lists.llvm.org>
To: llvm-dev@lists.llvm.org
Sent: Tuesday, February 9, 2016 11:40:21 AM
Subject: [llvm-dev] [RFC] Lanai backend
Hi all,
Hi Jacques,
We would like to contribute a new backend for the Lanai processor
I suppose I can guess from your e-mail address who “we” are?
Yep!
(derived from the processor described in [1]).
Lanai is a simple in-order 32-bit processor with:
Can you say a few words about what this is, in what hardware it appears, and how it can be used? Is this the Myricom processor? What version(s)?
This is internal hardware for us, so there’s not a lot we can share, and you can’t really grab a version of the hardware. If that’s a problem for the community, I completely understand.
Mostly, I wanted to offer to upstream this because it seems likely about the same utility as the AMDGPU backend for folks without an AMDGPU, or the XCore backend, etc. It’s small, and we’re happy maintaining it and taking on any of the effort around it. We’re also happy with the usual policy of if the maintainers stop showing up, the backend goes away.
But we’re working on the backend a bunch, and it didn’t make sense to keep it walled off. Especially if there is anything that can be reused in other backends and/or if there is any common infrastructure we need, this makes it easy to test.
Still, totally up to the community if they want this. =]
Aside from the Clang/LLVM support, what other software, drivers, etc. would be needed to make use of this support? What versions of that software?
This is a question for Jacques, I’ll let him fill in the details.
-Chandler
> From: "Jacques Pienaar via llvm-dev" <llvm-dev@lists.llvm.org>
> To: llvm-dev@lists.llvm.org
> Sent: Tuesday, February 9, 2016 11:40:21 AM
> Subject: [llvm-dev] [RFC] Lanai backend
> Hi all,
Hi Jacques,
> We would like to contribute a new backend for the Lanai processor
I suppose I can guess from your e-mail address who "we" are?
Yep!
> (derived from the processor described in [1]).
> Lanai is a simple in-order 32-bit processor with:
Can you say a few words about what this is, in what hardware it appears,
and how it can be used? Is this the Myricom processor? What version(s)?
This is internal hardware for us, so there's not a lot we can share, and
you can't really grab a version of the hardware. If that's a problem for
the community, I completely understand.
Mostly, I wanted to offer to upstream this because it seems likely about
the same utility as the AMDGPU backend for folks without an AMDGPU, or the
XCore backend, etc. It's small, and we're happy maintaining it and taking
on any of the effort around it. We're also happy with the usual policy of
if the maintainers stop showing up, the backend goes away.
But we're working on the backend a bunch, and it didn't make sense to keep
it walled off. Especially if there is anything that can be reused in other
backends and/or if there is any common infrastructure we need, this makes
it easy to test.
Still, totally up to the community if they want this. =]
Aside from the Clang/LLVM support, what other software, drivers, etc.
would be needed to make use of this support? What versions of that software?
This is a question for Jacques, I'll let him fill in the details.
Aside from Clang/LLVM support the only other software we use are linker
support in binutils. We have not submitted those yet but it is based on the
previous binutils used (GitHub - myri/lanai-binutils: Gnu Binary Utilities with Myricom Lanai processor support.) but
targeting ELF instead of COFF.
I was going to mention it, but you guys know very well the drill, so
unless this hardware changes fundamental parts of the middle end in
ways that are unnatural to most other targets (doesn't seem that way),
then I see no reason why not have it upstream.
However, there are no tests at all on the reviews, and that is a red
flag. I was expecting Clang driver tests, code-gen tests, instruction
encoding/decoding, ABI and frame lowering tests, etc. Without these, I
can't see the benefits of having the target upstream, since I'll have
no idea what your target is expected to do when I add/change some
generic code generation option.
cheers,
--renato
Yes, we do. But we needed to support linker scripts too else we’d have just used lld.
Best,
Jacques
I placed all the tests along with the backend in http://reviews.llvm.org/
D17002. I can definitely add some more tests.
Best,
Jacques
I see no problem with having the backend upstream with the understanding that all the normal policies apply. Getting more people working on ToT is valuable to the community as a whole and provided it’s “just another backend” with plenty of tests, the cost is low. Speaking of which, have we ever documented what those policies actually are?
That is fine. Lld is an independent project. MC is a core part of llvm and allows codegen (producing a .s) and assembling (producing a .o) to be tested in isolation.
So, given that this uses an existing format (ELF) and has MC support, no objections on my side if it includes tests and a description of any peculiarities the architecture has.
Cheers,
Rafael
Do you have a psABI document? Or an ISA reference? Or an encoding reference?
I know at least the encoding reference is missing for AArch64, so it’s not a huge deal, but anything we can put in http://llvm.org/docs/CompilerWriterInfo.html (docs/CompilerWriterInfo.rst) would be appreciated.
– Sean Silva
I added it in a while back. The "Architecture Reference Manual"
contains all that info. Perhaps I should reword it to make that
clearer for anyone coming along later.
Tim.
Hi Jacques,
We generally have a low bar for accepting new “experimental” backends, but I think that this is the first proposal to add a target for a hardware that general LLVM contributors can’t have access to. As such, we’ll have to figure out as a community whether this makes sense.
Here are the tradeoffs I see of accepting the backend:
1) I imagine that there is a big win for you, not having to merge with mainline. Maintaining an out of tree backend is a pain 
2) For the community, this is probably a net loss since changes to common codegen could would be required to update your backend, but no one else in the community would benefit from the target being in mainline.
3) There is probably a small but non-zero benefit to keeping your team working directly on mainline, since you’re more likely to do ancillary work in ToT. If your development is in mainline, this work is most likely to go into llvm.org instead of into your local branch.
4) There could be an educational benefit of having the backend, particularly if it has unique challenges to overcome.
What do others think about this? I know that several organizations have not even bothered proposing internal-only targets for inclusion in llvm.org, since they would effectively be contributing dead code that the community would have to maintain.
-Chris
The ISA & encoding is documented in the comments and diagrams of lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I’ll add a link to this tablegen in docs/CompilerWriterInfo.rst.
Thanks,
Jacques
My random view:
If the team is going to contribute more generally (IE do more than maintain the backend), it could be a net win for the community.
Otherwise, …
Some driveby comments -
If the processor isn't encumbered and by this I mean any company could
in theory make a "Lanai compatible" processor, then I personally would
be supportive or middle path. If on the other hand the processor is
highly proprietary or encumbered (patents?) then I'd more in the
middle or slightly against.
I can't always agree with all @google people and or their
comments/attitudes, but in general @google has built up quite a bit of
positive "karma", at least from my outside perspective. (I suspect
others probably see and may feel this way as well)
To compare against AMDGPU isn't really fair. AMDGPU may have "limited
use" as pointed out, but the niche community that does in fact use it
and care about it has high impact. The hardware is also publicly
available. /* In theory nothing gets in the way of AMD GPU's gaining
greater market adoption - I blame marketing more than technology since
they are strong on the current gen consoles */
It’d be be super-exciting if everyone working on random LLVM backends pushed their targets upstream, and then did their development on ToT! If this proposal would catalyze other organizations to submit their backends upstream as well, that would seem like a huge win.
I’d expect the benefit of having developers of such targets all working upstream to very much outweigh the usually minor cost of updating it for other codegen changes.
That only holds as long as there is an active maintainer, of course. If a target actually becomes deadweight, it should be removed as soon as possible.
> I know at least the encoding reference is missing for AArch64,
I added it in a while back. The "Architecture Reference Manual"
contains all that info. Perhaps I should reword it to make that
clearer for anyone coming along later.
I should have qualified my statement with "last I checked"
Can you annotate that link with "(authentication required, free sign-up)"
like some of the power docs do?
Also, if you're taking a look at this area, the link "ARMv8 Instruction Set
Overview" seems to be broken or out of date.
-- Sean Silva
Can you annotate that link with "(authentication required, free sign-up)"
like some of the power docs do?
Sounds like a good idea. Grrr ARM!
Also, if you're taking a look at this area, the link "ARMv8 Instruction Set
Overview" seems to be broken or out of date.
Yep.
Tim.