[llvm-dev] [RFC] Lanai backend

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 9 11:32:41 PST 2016


----- Original Message ----- 

> From: "Philip Reames" <listmail at philipreames.com>
> To: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel"
> <hfinkel at anl.gov>, "Jacques Pienaar" <jpienaar at google.com>
> Cc: llvm-dev at lists.llvm.org
> Sent: Tuesday, February 9, 2016 12:28:20 PM
> Subject: Re: [llvm-dev] [RFC] Lanai backend

> 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 > wrote:
> 

> > > ----- Original Message -----
> > 
> 
> > > > From: "Jacques Pienaar via llvm-dev" < llvm-dev at lists.llvm.org
> > > > >
> > 
> 
> > > > To: 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.

I completely agree.

> Speaking of which, have we ever documented what those policies
> actually are?

I don't believe so.

 -Hal

> > > 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
> 

-- 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list