[llvm-dev] [RFC] Lanai backend
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 9 10:28:20 PST 2016
On 02/09/2016 10:05 AM, Chandler Carruth via llvm-dev wrote:
> On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> ----- Original Message -----
> > From: "Jacques Pienaar via llvm-dev" <llvm-dev at lists.llvm.org
> <mailto:llvm-dev at lists.llvm.org>>
> > To: llvm-dev at lists.llvm.org <mailto:llvm-dev at 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 ).
> > 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. =]
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?
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev