21 ms·

LLVM 9.0

307 points by AndyKelley 7y ago

caspervonb 7y ago
That was fast, has the release cycle changed?
- favorited 7y ago
  LLVM changed their versioning scheme a few releases back (maybe around 3.9 -> 4.0 IIRC?), so major version increases will be more common now. I think it used to be roughly tied to bitcode compatibility? Someone who works on LLVM can give a more specific answer, but the gist of it is we'll see more major version increments now.
  - sanxiyn 7y ago
    http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... explains the exact change.
    - caspervonb 7y ago
      Ahh thanks!
- AndyKelley 7y ago
  No, it's been 6 months
ManDeJan 7y ago
Hey Andy, will this mean I can try (experimental) zig on risc-v in the near future? :))
- AndyKelley 7y ago
  llvm9 branch will be merged into master today (as soon as the CI infrastructure is updated with LLVM 9) and it has basic risc-v support in the std lib, as well as cross compilation targeting risc-v using glibc and musl. edit: [me updating the CI infrastructure](https://twitter.com/andy_kelley/status/1174769700343074818 https://twitter.com/andy_kelley/status/1174769700343074818)
cryptonector 7y ago
> LLVM will now remove stores to constant memory (since this is a contradiction) under the assumption the code in question must be dead. This has proven to be problematic for some C/C++ code bases which expect to be able to cast away ‘const’. This is (and has always been) undefined behavior, but up until now had not been actively utilized for optimization purposes in this exact way. For more information, please see: bug 42763 and post commit discussion. This will break all sorts of code. Often we have things that are const for callers of an API but not necessarily for the implementation of an API. Other cases are where an API should have used const but didn't and then got partly constified, and there are places where you still need to cast away const-ness.
- pubby 7y ago
  I don't see this change breaking the examples you have given. You can always modify non-const objects. What you can't do is modify const objects through a pointer to non-const. e.g. ((char*)"fooo")[0] = 1 is broken code but int x = 0; int const* y = &x; *((int*)y) = 1; is not.
  - cryptonector 7y ago
    That's not what I got from the quoted paragraph. I'll have to chase the links to be sure.
    - jcranmer 7y ago
      In LLVM terms, it's referring to these kinds of stores: @vval = constant double 1.0, align 8 define void @foo(double *val) { store double %val, double @cval, align 8 | At the LLVM level, the "const" qualifier to pointers and other non-global values get reflected nowhere in the type system. But if you declare a const global variable, that variable gets placed in a read-only data section.
      - cryptonector 7y ago
        Got it. Thanks!
trillic 7y ago
> Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang This is an awesome step!
lpage 7y ago
> "Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang" This is big. Support for asm goto was merged into the mainline earlier this year, but now it's released [1]. Aside from the obvious implications of this - being able to build the kernel with LLVM - working with eBPF/XDP just got way easier [2]. [1] https://github.com/llvm/llvm-project/commit/784929d0454c4df6a98ef6fbbd1d30a6f71f9c16 https://github.com/llvm/llvm-project/commit/784929d0454c4df6... [2] https://www.spinics.net/lists/netdev/msg544057.html https://www.spinics.net/lists/netdev/msg544057.html
- colechristensen 7y ago
  Can anyone give a good concise explanation as to why GOTO was not in LLVM from the beginning? It seems like something quite obvious to need. I can only guess that it had something to do with their compliation strategy not being able to deal with the ... nonlinearity* ... introduced by GOTO. *Probably a better word for that
  - nlewycky 7y ago
    GOTO was supported in LLVM from the beginning. The new feature is ASM GOTO. An ASM block is opaque to the compiler, and the compiler treats it similarly to a function call. A called function may contain control flow internal to itself, but can't cause control flow to happen in the caller. ASM GOTO is a new syntax for informing the compiler that this inline ASM may contain a GOTO to a given label. GCC added it around 4.5-ish, and LLVM is adding it in LLVM 9. *FYI, the name for the thing that GOTO permits which combinations of if and loops doesn't is called "unstructured control flow".
    - lpage 7y ago
      Pros of asm goto: it's useful for introducing low overhead tracing and debugging abstractions. Tracepoints in the Linux kernel are one example [1]. It's also used for implementing certain Meltdown/Spectre mitigations [2]. Cons of asm goto: as parent points out, asm blocks are largely opaque to the compiler, which stands in the way of optimization. Control flow analysis can't take into account internal jumps, and for GCC at least, every asm goto block gets flagged as volatile. That disables whole classes of optimization. Unless you're relying on hardware-specific instructions that the compiler doesn't know about or expose as an intrinsic, there's always an alternative to asm goto. That said, those alternatives might prove more expensive than the loss of optimizations precluded by the use of asm goto [2]. The pros/cons of including asm goto in clang were discussed in [3]. [1] https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.... [2] https://lwn.net/Articles/748074/ https://lwn.net/Articles/748074/ [3] http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239...
morning_gelato 7y ago
>Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang This is great for Linux, no longer being dependent on a single compiler for one of the most popular ISAs can only be a good thing for the overall health of the project. To be clear, I have nothing against gcc.
- wiz21c 7y ago
  2 cents prediction : Android will leave linux (fuschia), linux will leave gcc because companies developing the kernel will push for clang, clang will have media coverage, gcc will therefore loose a huge user base and the power of the FSF will go south. (as a free software zealot ( :-) ), I'm worried)
nitwit005 7y ago
> The optimizer will now convert calls to memcmp into a calls to bcmp in some circumstances. What is the improvement from that change? I thought they were essentially the same.
- Someone 7y ago
  memcmp has to find the first offset where the buffers differ, and check which of them is larger. bcmp only has to figure out whether the buffers differ. It doesn’t have to figure out where they differ. For example, for s=1024, bcmp can do (at most) 128 64-bit compares (using vector registers, it could even use larger steps) memcmp could do the same, with an additional “figure out where in the last 8-byte parts compared the difference lies”. That’s an amount of work that’s independent of the buffer sizes, so it wouldn’t add much, relatively, _if_ the buffers compared are large and the difference (if any) most of the time is near the end of the buffers. I doubt those ifs often hold, though.
  - tedunangst 7y ago
    This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.
    - saagarjha 7y ago
      The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.
      - tedunangst 7y ago
        The release notes go on to say that you may need to provide your own implementation of bcmp, which does not sound very intrinsic.
        saagarjha 7y ago
        Huh, interesting. I was assuming that the compiler would statically link in a bcmp in that case, but it looks like it will literally replace it with a call to bcmp in certain cases (as defined by the remainder of that point in the release notes). Apparently this was brought up and brushed aside as not an issue: https://bugs.llvm.org/show_bug.cgi?id=41035 https://bugs.llvm.org/show_bug.cgi?id=41035
KindOne 7y ago
Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux https://github.com/ClangBuiltLinux/linux
- cormacrelf 7y ago
  "This branch is even with torvalds:master." Does that mean there are no patches necessary for any GCC builtins? Or does the actual clang-buildable part live on another branch?
  - brackle 7y ago
    With LLVM 9, it is now possible to build the Linux kernel with no patches (for x86_64). https://www.phoronix.com/scan.php?page=article&item=clang-linux-53&num=1 https://www.phoronix.com/scan.php?page=article&item=clang-li...
    - ndesaulniers 7y ago
      Note: we also build+boot under CI: * arm (v5, v6, v7) * arm64 (v8) * ppc32 * ppc64 * x86_64 * mips https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/128315291 https://travis-ci.com/ClangBuiltLinux/continuous-integration...
  - BurningCycles 7y ago
    Yes, there are still some stability issues though. Phoronix benchmarked the Linux kernel built with Clang/LLVM against GCC recently: https://www.phoronix.com/scan.php?page=article&item=clang-linux-53&num=1 https://www.phoronix.com/scan.php?page=article&item=clang-li...
    - ndesaulniers 7y ago
      Android and CrOS have not had stability issues related to the compiler since switching to Clang. And Phoronix didn't send me any reports; I reached out to Michael and he said he'll send them to me next time he tries.
brynet 7y ago
Note that this release (9.x) marks the first to be no longer available under the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And not just the compiler itself, but also sub-projects like the supporting libc++/libc++abi standard libraries. This change only happened due to corporate pressure, and was done without considering the larger impact towards the open source community. This will undoubtedly effect many projects and companies alike going forward, but notably the OpenBSD project can no longer merge in new changes, which will ship with 8.0.1 later this year in 6.6. The Apache 2.0 license is not considered permissive enough to be included in the base system of OpenBSD, it muddies the line between Copyright law and US Contract law; adding additional restrictions related to patents that may terminate rights. https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.html https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.... https://www.openbsd.org/policy.html https://www.openbsd.org/policy.html It is very unfortunate that the LLVM project has ignored the concerns expressed by developers of an open source operating system project that have been eagerly adopting a clang based toolchain, across many platforms (arm64/armv7/i386/amd64/octeon/..) by default, and has been working on new innovative security mitigations (RETGUARD, ROPGadgetFixup framework, register allocator rearranging) along the way. I will take this opportunity to ask, if you're a current LLVM developer/contributor, please consider making your changes also available under the terms of the original permissive license. For example, explicitly stating publically as such when mailing patchsets or pull requests. This would save having to privately ask permission to backport changes on case-by-case basis. https://github.com/llvm/llvm-project/blob/release/8.x/clang/LICENSE.TXT https://github.com/llvm/llvm-project/blob/release/8.x/clang/...
- jcranmer 7y ago
  > This change only happened due to corporate pressure, and was done without considering the impact towards the open source community. FWIW, it's worth noting that only OpenBSD has this stance, and it was brought up a few times on the mailing list. The general summary is that "every lawyer we've had look into this issue has said that OpenBSD's fears about the patent licensing clauses are FUD, and OpenBSD has provided no legal opinions to back its claims up."
shmerl 7y ago
Meanwhile, Mesa developers merged ACO compiler for AMDGPU, as the future replacement for llvm.
- ndesaulniers 7y ago
  Fun fact; AMDGPU driver can't run when built with LLVM right now because they: 1. build their driver with a stack alignment of 16B (standard for x86_64 userspace). 2. use floating point in the kernel, which the kernel has limited support for. 3. The rest of the x86_64 kernel uses 8B stack alignment. Code from 3 calls into 1. And then they have sse2 instructions in their driver (double precision arithmetic). Guess what happens?
  - shmerl 7y ago
    Why does it work with gcc?
    - ndesaulniers 7y ago
      GCC just so happens to not select any instructions with alignment requirements at `-msse -mno-sse2`, while clang emits calls to soft-fp functions that aren't implemented in the kernel. At -msse2, clang emits sse2 instructions with alignment requirements. You'd think their 16B-aligned-stack driver would be ok, but its caller (the rest of the kernel) has a different ABI (8B-aligned-stack) which is kind of insane to mix TUs with two different ABIs in the same executable and make calls between them. Then again, all x86_64 processors support sse2, so I'm not surprised that Clang at -mno-sse2 doesn't work better. There's numerous bugs filed against Clang where it crashes when -mno-sse2 is set, but double precision floating point is used. (I've spent almost all of this week debugging this, and working with CrOS and AMD engineers on this. It's not clear to me at this point whether the 16B-stack-alignment ABI change was well intentioned or a stroke of luck).
  - trasz 7y ago
    Fun fact - they do work fine... under FreeBSD :-)
truth_seeker 7y ago
Good to see LLVM IR becoming the ultimate bridge between Software and Hardware

LLVM 9.0

307 points by AndyKelley 7y ago

caspervonb 7y ago

That was fast, has the release cycle changed?

favorited 7y ago
LLVM changed their versioning scheme a few releases back (maybe around 3.9 -> 4.0 IIRC?), so major version increases will be more common now. I think it used to be roughly tied to bitcode compatibility? Someone who works on LLVM can give a more specific answer, but the gist of it is we'll see more major version increments now.
- sanxiyn 7y ago
  http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... explains the exact change.
  - caspervonb 7y ago
    Ahh thanks!
AndyKelley 7y ago
No, it's been 6 months

ManDeJan 7y ago

Hey Andy, will this mean I can try (experimental) zig on risc-v in the near future? :))

AndyKelley 7y ago
llvm9 branch will be merged into master today (as soon as the CI infrastructure is updated with LLVM 9) and it has basic risc-v support in the std lib, as well as cross compilation targeting risc-v using glibc and musl. edit: [me updating the CI infrastructure](https://twitter.com/andy_kelley/status/1174769700343074818 https://twitter.com/andy_kelley/status/1174769700343074818)

cryptonector 7y ago

> LLVM will now remove stores to constant memory (since this is a contradiction) under the assumption the code in question must be dead. This has proven to be problematic for some C/C++ code bases which expect to be able to cast away ‘const’. This is (and has always been) undefined behavior, but up until now had not been actively utilized for optimization purposes in this exact way. For more information, please see: bug 42763 and post commit discussion. This will break all sorts of code. Often we have things that are const for callers of an API but not necessarily for the implementation of an API. Other cases are where an API should have used const but didn't and then got partly constified, and there are places where you still need to cast away const-ness.

pubby 7y ago
I don't see this change breaking the examples you have given. You can always modify non-const objects. What you can't do is modify const objects through a pointer to non-const. e.g. ((char*)"fooo")[0] = 1 is broken code but int x = 0; int const* y = &x; *((int*)y) = 1; is not.
- cryptonector 7y ago
  That's not what I got from the quoted paragraph. I'll have to chase the links to be sure.
  - jcranmer 7y ago
    In LLVM terms, it's referring to these kinds of stores: @vval = constant double 1.0, align 8 define void @foo(double *val) { store double %val, double @cval, align 8 | At the LLVM level, the "const" qualifier to pointers and other non-global values get reflected nowhere in the type system. But if you declare a const global variable, that variable gets placed in a read-only data section.
    - cryptonector 7y ago
      Got it. Thanks!

trillic 7y ago

> Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang This is an awesome step!

lpage 7y ago

> "Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang" This is big. Support for asm goto was merged into the mainline earlier this year, but now it's released [1]. Aside from the obvious implications of this - being able to build the kernel with LLVM - working with eBPF/XDP just got way easier [2]. [1] https://github.com/llvm/llvm-project/commit/784929d0454c4df6a98ef6fbbd1d30a6f71f9c16 https://github.com/llvm/llvm-project/commit/784929d0454c4df6... [2] https://www.spinics.net/lists/netdev/msg544057.html https://www.spinics.net/lists/netdev/msg544057.html

colechristensen 7y ago
Can anyone give a good concise explanation as to why GOTO was not in LLVM from the beginning? It seems like something quite obvious to need. I can only guess that it had something to do with their compliation strategy not being able to deal with the ... nonlinearity* ... introduced by GOTO. *Probably a better word for that
- nlewycky 7y ago
  GOTO was supported in LLVM from the beginning. The new feature is ASM GOTO. An ASM block is opaque to the compiler, and the compiler treats it similarly to a function call. A called function may contain control flow internal to itself, but can't cause control flow to happen in the caller. ASM GOTO is a new syntax for informing the compiler that this inline ASM may contain a GOTO to a given label. GCC added it around 4.5-ish, and LLVM is adding it in LLVM 9. *FYI, the name for the thing that GOTO permits which combinations of if and loops doesn't is called "unstructured control flow".
  - lpage 7y ago
    Pros of asm goto: it's useful for introducing low overhead tracing and debugging abstractions. Tracepoints in the Linux kernel are one example [1]. It's also used for implementing certain Meltdown/Spectre mitigations [2]. Cons of asm goto: as parent points out, asm blocks are largely opaque to the compiler, which stands in the way of optimization. Control flow analysis can't take into account internal jumps, and for GCC at least, every asm goto block gets flagged as volatile. That disables whole classes of optimization. Unless you're relying on hardware-specific instructions that the compiler doesn't know about or expose as an intrinsic, there's always an alternative to asm goto. That said, those alternatives might prove more expensive than the loss of optimizations precluded by the use of asm goto [2]. The pros/cons of including asm goto in clang were discussed in [3]. [1] https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.... [2] https://lwn.net/Articles/748074/ https://lwn.net/Articles/748074/ [3] http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239...

morning_gelato 7y ago

>Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang This is great for Linux, no longer being dependent on a single compiler for one of the most popular ISAs can only be a good thing for the overall health of the project. To be clear, I have nothing against gcc.

wiz21c 7y ago
2 cents prediction : Android will leave linux (fuschia), linux will leave gcc because companies developing the kernel will push for clang, clang will have media coverage, gcc will therefore loose a huge user base and the power of the FSF will go south. (as a free software zealot ( :-) ), I'm worried)

nitwit005 7y ago

> The optimizer will now convert calls to memcmp into a calls to bcmp in some circumstances. What is the improvement from that change? I thought they were essentially the same.

Someone 7y ago
memcmp has to find the first offset where the buffers differ, and check which of them is larger. bcmp only has to figure out whether the buffers differ. It doesn’t have to figure out where they differ. For example, for s=1024, bcmp can do (at most) 128 64-bit compares (using vector registers, it could even use larger steps) memcmp could do the same, with an additional “figure out where in the last 8-byte parts compared the difference lies”. That’s an amount of work that’s independent of the buffer sizes, so it wouldn’t add much, relatively, _if_ the buffers compared are large and the difference (if any) most of the time is near the end of the buffers. I doubt those ifs often hold, though.
- tedunangst 7y ago
  This would be true, except bcmp has been removed from posix some years ago. There's no particular requirement that a function called bcmp does what you expect.
  - saagarjha 7y ago
    The compiler will surely use a (most likely intrinsic) function with appropriate semantics in that case.
    - tedunangst 7y ago
      The release notes go on to say that you may need to provide your own implementation of bcmp, which does not sound very intrinsic.
      - saagarjha 7y ago
        Huh, interesting. I was assuming that the compiler would statically link in a bcmp in that case, but it looks like it will literally replace it with a call to bcmp in certain cases (as defined by the remainder of that point in the release notes). Apparently this was brought up and brushed aside as not an issue: https://bugs.llvm.org/show_bug.cgi?id=41035 https://bugs.llvm.org/show_bug.cgi?id=41035

KindOne 7y ago

Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux https://github.com/ClangBuiltLinux/linux

cormacrelf 7y ago
"This branch is even with torvalds:master." Does that mean there are no patches necessary for any GCC builtins? Or does the actual clang-buildable part live on another branch?
- brackle 7y ago
  With LLVM 9, it is now possible to build the Linux kernel with no patches (for x86_64). https://www.phoronix.com/scan.php?page=article&item=clang-linux-53&num=1 https://www.phoronix.com/scan.php?page=article&item=clang-li...
  - ndesaulniers 7y ago
    Note: we also build+boot under CI: * arm (v5, v6, v7) * arm64 (v8) * ppc32 * ppc64 * x86_64 * mips https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/128315291 https://travis-ci.com/ClangBuiltLinux/continuous-integration...
- BurningCycles 7y ago
  Yes, there are still some stability issues though. Phoronix benchmarked the Linux kernel built with Clang/LLVM against GCC recently: https://www.phoronix.com/scan.php?page=article&item=clang-linux-53&num=1 https://www.phoronix.com/scan.php?page=article&item=clang-li...
  - ndesaulniers 7y ago
    Android and CrOS have not had stability issues related to the compiler since switching to Clang. And Phoronix didn't send me any reports; I reached out to Michael and he said he'll send them to me next time he tries.

brynet 7y ago

Note that this release (9.x) marks the first to be no longer available under the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And not just the compiler itself, but also sub-projects like the supporting libc++/libc++abi standard libraries. This change only happened due to corporate pressure, and was done without considering the larger impact towards the open source community. This will undoubtedly effect many projects and companies alike going forward, but notably the OpenBSD project can no longer merge in new changes, which will ship with 8.0.1 later this year in 6.6. The Apache 2.0 license is not considered permissive enough to be included in the base system of OpenBSD, it muddies the line between Copyright law and US Contract law; adding additional restrictions related to patents that may terminate rights. https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.html https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.... https://www.openbsd.org/policy.html https://www.openbsd.org/policy.html It is very unfortunate that the LLVM project has ignored the concerns expressed by developers of an open source operating system project that have been eagerly adopting a clang based toolchain, across many platforms (arm64/armv7/i386/amd64/octeon/..) by default, and has been working on new innovative security mitigations (RETGUARD, ROPGadgetFixup framework, register allocator rearranging) along the way. I will take this opportunity to ask, if you're a current LLVM developer/contributor, please consider making your changes also available under the terms of the original permissive license. For example, explicitly stating publically as such when mailing patchsets or pull requests. This would save having to privately ask permission to backport changes on case-by-case basis. https://github.com/llvm/llvm-project/blob/release/8.x/clang/LICENSE.TXT https://github.com/llvm/llvm-project/blob/release/8.x/clang/...

jcranmer 7y ago
> This change only happened due to corporate pressure, and was done without considering the impact towards the open source community. FWIW, it's worth noting that only OpenBSD has this stance, and it was brought up a few times on the mailing list. The general summary is that "every lawyer we've had look into this issue has said that OpenBSD's fears about the patent licensing clauses are FUD, and OpenBSD has provided no legal opinions to back its claims up."

shmerl 7y ago

Meanwhile, Mesa developers merged ACO compiler for AMDGPU, as the future replacement for llvm.

ndesaulniers 7y ago
Fun fact; AMDGPU driver can't run when built with LLVM right now because they: 1. build their driver with a stack alignment of 16B (standard for x86_64 userspace). 2. use floating point in the kernel, which the kernel has limited support for. 3. The rest of the x86_64 kernel uses 8B stack alignment. Code from 3 calls into 1. And then they have sse2 instructions in their driver (double precision arithmetic). Guess what happens?
- shmerl 7y ago
  Why does it work with gcc?
  - ndesaulniers 7y ago
    GCC just so happens to not select any instructions with alignment requirements at `-msse -mno-sse2`, while clang emits calls to soft-fp functions that aren't implemented in the kernel. At -msse2, clang emits sse2 instructions with alignment requirements. You'd think their 16B-aligned-stack driver would be ok, but its caller (the rest of the kernel) has a different ABI (8B-aligned-stack) which is kind of insane to mix TUs with two different ABIs in the same executable and make calls between them. Then again, all x86_64 processors support sse2, so I'm not surprised that Clang at -mno-sse2 doesn't work better. There's numerous bugs filed against Clang where it crashes when -mno-sse2 is set, but double precision floating point is used. (I've spent almost all of this week debugging this, and working with CrOS and AMD engineers on this. It's not clear to me at this point whether the 16B-stack-alignment ABI change was well intentioned or a stroke of luck).
- trasz 7y ago
  Fun fact - they do work fine... under FreeBSD :-)

truth_seeker 7y ago

Good to see LLVM IR becoming the ultimate bridge between Software and Hardware