Live data from Hacker News

Lanai, the mystery CPU architecture in LLVM

q3k.org

21–30 of 163 posts

Re: Lanai, the mystery CPU architecture in LLVM

#21

This seems related https://github.com/chriseth/notes/blob/186d7ea0742336ed38e39... "TrueBit - Off-Chain Computations for Smart Contracts"

This is https://github.com/TrueBitProject/lanai , which is in itself an interesting endeavor which I forgot to write about. I've added a mention about it to TFA.

Re: Lanai, the mystery CPU architecture in LLVM

#22

I gotta say, if I was the BDFL of llvm, I would kick this out of tree without a second thought. Why on earth should a foss project support a private architecture? How many man-hours have been wasted waiting for the Lanai backend to compile? Not to mention applying project-wide refactoring to the Lanai code.

There's more context in the thread where it was upstreamed: https://lists.llvm.org/pipermail/llvm-dev/2016-February/0951...

Some notable comments:

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

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

Re: Lanai, the mystery CPU architecture in LLVM

#23
post #14

Earlier quoted context omitted.

Google isn't really forcing anyone to do anything in this case. Another RISC backend that was made clear would be ripped out of upstream the instant the Google maintainers stopped responding isn't really an imposition.

Would something like this be accepted in open source projects that are not significantly driven by Google? E.g. would Linux accept code for drivers / architectures that are not available to the public? I'm genuinely curious.

xcore (mentioned in that thread) is pretty obscure and still in trunk last I looked. Extra backends don't carry that much of a maintenance cost, mostly patching them up on api changes. Weirder targets hit bugs that the common ones don't so there's a benefit from having them in tree too.

I'm not sure that generalises beyond modular compilers though.

Re: Lanai, the mystery CPU architecture in LLVM

#24

I gotta say, if I was the BDFL of llvm, I would kick this out of tree without a second thought. Why on earth should a foss project support a private architecture? How many man-hours have been wasted waiting for the Lanai backend to compile? Not to mention applying project-wide refactoring to the Lanai code.

A significant part of work on LLVM comes from Apple, which includes support for quirks of _their_ proprietary chips and platform; and the world is much better for those changes being upstreamed rather than living in a fork somewhere.

Re: Lanai, the mystery CPU architecture in LLVM

#25

I gotta say, if I was the BDFL of llvm, I would kick this out of tree without a second thought. Why on earth should a foss project support a private architecture? How many man-hours have been wasted waiting for the Lanai backend to compile? Not to mention applying project-wide refactoring to the Lanai code.

[deleted]

Re: Lanai, the mystery CPU architecture in LLVM

#27
post #12
post #4

I worked for Myricom 2001->2013, and Google 2013->2015. And, wow, I wish I could comment on this thread.. :) EDIT: Scott's Medium blog post linked from this article is fascinating: https://medium.com/swlh/myricom-an-hpc-story-and-lessons-lea...

Why can you not comment? Certainly any NDA you signed must be expired by now. PSA: If you are not getting continuing payments, any contracts you signed are void. Technically, I gather you are supposed to notify the other party that you are terminating your participation in the contract. Even if you are getting ongoing payments, you can opt out of that, too. (This is not legal advice. Consult an actual lawyer for anyt…

It is absolutely not the case that you can just quit a company, wait a year, and then dump all their confidential information.

Even if there were no legal repercussions (which there are), that's a great way to never be hired again.

Re: Lanai, the mystery CPU architecture in LLVM

#29

I gotta say, if I was the BDFL of llvm, I would kick this out of tree without a second thought. Why on earth should a foss project support a private architecture? How many man-hours have been wasted waiting for the Lanai backend to compile? Not to mention applying project-wide refactoring to the Lanai code.

> How many man-hours have been wasted waiting for the Lanai backend to compile?

Probably zero? Is it compiled by default?

Re: Lanai, the mystery CPU architecture in LLVM

#30
post #4

I worked for Myricom 2001->2013, and Google 2013->2015. And, wow, I wish I could comment on this thread.. :) EDIT: Scott's Medium blog post linked from this article is fascinating: https://medium.com/swlh/myricom-an-hpc-story-and-lessons-lea...

I just want to know why it needs to be in-tree.

LLVM doesn't have a plugin system so it's that, or maintain a fork and deal with horrible merges all the time.
Post reply on HN