5 ms·

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 architectur

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.

judofyr 5y ago
There's more context in the thread where it was upstreamed: https://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html 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.
klausa 5y ago
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.
- mjw1007 5y ago
  There's a big difference between "we are the only people who sell hardware using these chips" and "we are the only people who have access to hardware using these chips".
deleted 5y ago
[deleted]
tedunangst 5y ago
> How many man-hours have been wasted waiting for the Lanai backend to compile? Probably zero? Is it compiled by default?
- jcelerier 5y ago
  Yes. Run `strings /usr/lib/libLLVM.so| grep -i Lanai` to check on your version ; mine has all the relevant symbols
  - tedunangst 5y ago
    Oh, wow. I'm honestly surprised. My build does not.
    - jcelerier 5y ago
      afaik, by default LLVM builds support for all its supported architectures, I guess you passed -DLLVM_TARGETS_TO_BUILD="X86" or something to cmake when building your llvm ?
Someone 5y ago
Removing architectures because they’re obsolete/maintainers can’t be found, I can see (and the llvm maintainers agree. They removed Alpha at some time, for example), but because they’re proprietary? That would mean kicking out x86, x64, ARM, AMD Terascale, IBM’s z/architecture, etc. I’m sure clang would be very happy with that.
- speed_spread 5y ago
  Lanai is more than just proprietary, it's an entirely private architecture.
nickm12 5y ago
That was my first reaction, too, but then I had a second thought. Google is going to do this work on this in-tree or out-of-tree. If it is done in-tree, then there is a possibility that it will lead to core improvements that would benefit all backends. If out-of-tree, those are guaranteed to happen. I don't think it's a slam dunk, but on the balance it could make sense. And once it is in-tree you can actually validate this hypothesis by seeing the impact (or not) of contributions from Google.

judofyr 5y ago

There's more context in the thread where it was upstreamed: https://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html 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.

klausa 5y ago

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.

mjw1007 5y ago
There's a big difference between "we are the only people who sell hardware using these chips" and "we are the only people who have access to hardware using these chips".

deleted 5y ago

[deleted]

tedunangst 5y ago

> How many man-hours have been wasted waiting for the Lanai backend to compile? Probably zero? Is it compiled by default?

jcelerier 5y ago
Yes. Run `strings /usr/lib/libLLVM.so| grep -i Lanai` to check on your version ; mine has all the relevant symbols
- tedunangst 5y ago
  Oh, wow. I'm honestly surprised. My build does not.
  - jcelerier 5y ago
    afaik, by default LLVM builds support for all its supported architectures, I guess you passed -DLLVM_TARGETS_TO_BUILD="X86" or something to cmake when building your llvm ?

Someone 5y ago

Removing architectures because they’re obsolete/maintainers can’t be found, I can see (and the llvm maintainers agree. They removed Alpha at some time, for example), but because they’re proprietary? That would mean kicking out x86, x64, ARM, AMD Terascale, IBM’s z/architecture, etc. I’m sure clang would be very happy with that.

speed_spread 5y ago
Lanai is more than just proprietary, it's an entirely private architecture.

nickm12 5y ago

That was my first reaction, too, but then I had a second thought. Google is going to do this work on this in-tree or out-of-tree. If it is done in-tree, then there is a possibility that it will lead to core improvements that would benefit all backends. If out-of-tree, those are guaranteed to happen. I don't think it's a slam dunk, but on the balance it could make sense. And once it is in-tree you can actually validate this hypothesis by seeing the impact (or not) of contributions from Google.