1. 48
  1. 11

    I always thought LLVM had strict standards in terms of requiring freely available simulation tools, open docs, relevancy, etc. - then turns out some undocumented-for-years-except-early-revisions ISA gets in because Google uses it internally? Seems odd.

    1. 5

      https://lists.llvm.org/pipermail/llvm-dev/2016-February/095123.html has more on this:

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

    2. 10

      I’m implementing LLD support for Lanai.

      As the person who de facto maintains lld/ELF, I am hoping we don’t upstreaming Lanai port to lld/ELF. If we use Clang’s criteria for extensions https://clang.llvm.org/get_involved.html , I believe Lanai fails the “Evidence of a significant user community” bullet point.. The Lanai change will very likely benefit no user at all and just add maintenance burden. Just because llvm/lib/Target/X exists does not necessarily mean we need compiler-rt, lld, etc support. It does make the toolchain appear more complute, but who is going to use it? Such changes may have educational values but can be a significant cost for maintaining. As some folks may know, some passes of lld need significant rework (i.e. start to pay attention to multit-threading) to catch up a bit with mold. I have found that mips and powerpc64 have contributed some stuff which may at least make relocation scan parallelism complicated. While not that significant, Hexagon has some quirks and adds complexity as well. I wish we do not have more possibly architectures with quirky requirements.

      If just for retrocomputing purposes, (a) not upstreaming the code is an option (b) shift focus to retrocomputing architectures (e.g. m68k which LLVM gets a target kinda recently) with more significant user community is another (I do not necessarily imply that we need m68k for lld/ELF. If it does not have quirky stuff, it may be an option.)

      1. 7

        I am at awe how someone has so much free time that they are porting rust to an obscure CPU platform nobody uses for the fun of it. I mean this in a positive way. My life does not allow that right now and I am a little bit envious.