[llvm-dev] [RFC] Lanai backend

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 10 09:58:01 PST 2016


On 10 February 2016 at 17:41, Philip Reames via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 1) This is a highly visible clue as to what Google is running internally
> (admittedly, we don't know for what).  Given how secretive companies tend to
> be about such things, providing an incentive (upstreaming) to talk publicly
> about internal infrastructure is valuable.  I could see that being very
> useful to academics evaluating hardware ideas for instance.

It may be just me, but I'm not even remotely interested in what
companies are doing behind closed doors.

AFAICS, this move is just cost saving to Google, which is ok, but
let's not make it more than it really is.


> 2) Just because a backend generates code which isn't "officially" runnable
> doesn't mean there aren't people who'd be interested in using it.  For
> instance, reverse engineering for security analysis, open source software on
> otherwise closed hardware,

Reverse engineering assumes practical interest, but if there is no
practical way to use, there this is something that might just interest
Google.


> and supporting legacy products after the
> manufacture drops support are all realistic use cases.

Well, this point is moot for this discussion... :)


> 3) By getting more people involved in the open source project, we have an
> opportunity to further infect people inside companies with the desire to be
> good citizens in the community.  :)  That could be a very positive thing for
> all of us and the project as a whole in the long run.

This is an interesting perspective, though I'm not sure how much we
can expect and even verify.


> Pete wrote:
> Finally, one option is to have perpetually experimental backends.  Then all
> the code is in tree but no-one in tree should ever be expected to update it.

Exhibit #A: The CPPBackend. :)

cheers,
--renato


More information about the llvm-dev mailing list