4 ms·

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :(

krasin 11y ago
Out-of-tree targets for LLVM are generally a bad idea given how fast LLVM is changed. Every change could break the out-of-tree target, and being out-of-tree, there's no way the upstream developers could notice that.
- sklogic 11y ago
  The other side of this approach is that when the mainline developers do not have much love to a particular platform, it is dropped altogether with little to no remorse - see the fate of Microblaze support, or even the good ol' C backend. I wish we had a more stable API (maybe with a transformation layer) for the backends that may not probably need much of the new features. If LLVM had a maintained transformation layer from the "current" SelectionDAG to a stable one, it would have helped a lot.
DannyBee 11y ago
"A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :( Have you considered this is a deliberate decision, with a goal of having most targets in-tree? :)
- duaneb 11y ago
  Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.
  - sanxiyn 11y ago
    It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.
    - crazysim 11y ago
      Does Apple have some proprietary backends? I guess they have the resources to maintain such.
      - duaneb 11y ago
        Yes, they definitely do.
        gsnedders 11y ago
        Like what, nowadays? I know their ARM64 backend was, but what is now? Do they still maintain forks of them? (With more target data for their SoCs?)
        jevinskie 11y ago
        GPUs.
        willvarfar 11y ago
        Swift is still out-of-tree.
    - ashitlerferad 11y ago
      Sounds like the LLVM project should be using the GPL. This constant churn kind of turns the MIT license into the GPL but only for small companies and individuals who can't keep up with the churn. I guess that is why Apple likes LLVM.
    - sklogic 11y ago
      There is a reason proprietary backends would always be necessary. Hardware companies are very touchy about the patents, and not publishing an ISA-related work may often be the only way to protect from the trolls. Such companies would often encourage (privately or publicly) clean room 3rd party backends, and I'm pretty sure that the one we're discussing here is exactly of this kind. But they would be scared to death to allow any of their employees to even send a tiny patch to a compiler backend, if it could expose some microarchitecture knowledge that was not published.
- willvarfar 11y ago
  Which makes developing a large backend a lot of pointless busywork with patchsets touching parts of the codebase that really ought not need touching at all :( (I'm someone who was stuck on 3.6 for ages because of the pain of keeping up with the trunk)
Joky 11y ago
It depends what you mean by "plugin": targets are configured at compile time. I don't think you can build LLVM and then dynamically load a backend as plugin.
- willvarfar 11y ago
  You can load targets as plugins in llc :) You cannot load targets as plugins in clang :(

krasin 11y ago

Out-of-tree targets for LLVM are generally a bad idea given how fast LLVM is changed. Every change could break the out-of-tree target, and being out-of-tree, there's no way the upstream developers could notice that.

sklogic 11y ago
The other side of this approach is that when the mainline developers do not have much love to a particular platform, it is dropped altogether with little to no remorse - see the fate of Microblaze support, or even the good ol' C backend. I wish we had a more stable API (maybe with a transformation layer) for the backends that may not probably need much of the new features. If LLVM had a maintained transformation layer from the "current" SelectionDAG to a stable one, it would have helped a lot.

DannyBee 11y ago

"A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :( Have you considered this is a deliberate decision, with a goal of having most targets in-tree? :)

duaneb 11y ago
Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.
- sanxiyn 11y ago
  It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.
  - crazysim 11y ago
    Does Apple have some proprietary backends? I guess they have the resources to maintain such.
    - duaneb 11y ago
      Yes, they definitely do.
      - gsnedders 11y ago
        Like what, nowadays? I know their ARM64 backend was, but what is now? Do they still maintain forks of them? (With more target data for their SoCs?)
        jevinskie 11y ago
        GPUs.
        willvarfar 11y ago
        Swift is still out-of-tree.
  - ashitlerferad 11y ago
    Sounds like the LLVM project should be using the GPL. This constant churn kind of turns the MIT license into the GPL but only for small companies and individuals who can't keep up with the churn. I guess that is why Apple likes LLVM.
  - sklogic 11y ago
    There is a reason proprietary backends would always be necessary. Hardware companies are very touchy about the patents, and not publishing an ISA-related work may often be the only way to protect from the trolls. Such companies would often encourage (privately or publicly) clean room 3rd party backends, and I'm pretty sure that the one we're discussing here is exactly of this kind. But they would be scared to death to allow any of their employees to even send a tiny patch to a compiler backend, if it could expose some microarchitecture knowledge that was not published.
willvarfar 11y ago
Which makes developing a large backend a lot of pointless busywork with patchsets touching parts of the codebase that really ought not need touching at all :( (I'm someone who was stuck on 3.6 for ages because of the pain of keeping up with the trunk)

Joky 11y ago

It depends what you mean by "plugin": targets are configured at compile time. I don't think you can build LLVM and then dynamically load a backend as plugin.

willvarfar 11y ago
You can load targets as plugins in llc :) You cannot load targets as plugins in clang :(