[llvm-dev] [RFC] Lanai backend

[Philip Reames via llvm-dev]

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?
>
>
> 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. =]
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.
>
> -Chandler
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/e4806c70/attachment.html>