[HN Gopher] LLVM 12
___________________________________________________________________
LLVM 12
Author : samber
Score : 145 points
Date : 2021-04-16 11:21 UTC (10 hours ago)
(HTM) web link (releases.llvm.org)
(TXT) w3m dump (releases.llvm.org)
| snvzz wrote:
| As m68k support has been merged, I am looking forward to the next
| major LLVM release.
| mshockwave wrote:
| M68k LLVM maintainer here: I'm also excited about it :-) I'll
| try my best to write a proper release note.
| nicklecompte wrote:
| I don't read LLVM release notes very often and had a possibly
| stupid question:
|
| > Changes to the ARM Backend
|
| > During this release ...
|
| And that's all it says. Is this just a placeholder that wasn't
| deleted? Or an indication that there were changes but they are
| too minor/technical to usefully detail? There are many empty
| sections but only a handful have the "during this release..."
| boilerplate.
| dindresto wrote:
| Yeah, the whole page reads like a draft
| marco_craveiro wrote:
| Yes, I suspect the release notes are still being worked on. Or
| at least, I never noticed these sort of statements in the past.
| bombcar wrote:
| > Note that if you are reading this file from a Git checkout or
| the main LLVM web page, this document applies to the next
| release, not the current one. To see the release notes for a
| specific release, please see the releases page.
|
| That seems to indicate that it's a work in progress and someone
| forgot to do a cleanup process for things that didn't change.
| bla3 wrote:
| It does look like they missed the "write release notes" part of
| the release playbook. ...does LLVM have a release playbook? Is
| it public?
| snvzz wrote:
| I haven't been able to find this so I ask: Does LLVM have an
| assembler? Not the llvm bytecode (llvm-as), but architecture-
| specific code (like gas, the gnu assembler).
| bla3 wrote:
| Yes. "clang Foo.S" will use a built-in assembler. "llvm-mc" is
| another command line interface to that same assembler library.
| tankfeeder wrote:
| Picolisp supports IR from llvm12 and llvm13-nightly works too.
| volta83 wrote:
| How does perf compare against GCC?
|
| How well can it target nvidia GPUs?
|
| Does machine code analyzer support in order hardware yet ?
| vlovich123 wrote:
| 1. Phoronix regularly releases benchmarks. You should look at
| them. At the end of the day it's all workload-dependent and
| they trade off the performance crown.
|
| 2. Do you mean this [1]? If so then for a while it seems.
|
| 3. I don't understand the question. I can't find anything
| called a "machine code analyzer" or how the code analyzer/or
| any sanitizers relate to in-order vs out-of-order hardware as a
| class. The former works at source level. The latter is a
| mixture of library support code and codegen instrumentation and
| I'm not aware of anything specifically that relies on the
| execution mode of a CPU (I would imagine RAM constraints are
| the bigger issue).
|
| [1] https://www.hahnjo.de/blog/2018/10/08/clang-7.0-openmp-
| offlo...
| muizelaar wrote:
| llvm-mca
| mhh__ wrote:
| LLVM has a project called mca which reused the machine
| description files used for instruction scheduling to model
| the throughout of a basic block in steady state.
|
| Sounds cool, is cool - word of warning: it can be a little
| optimistic sometimes.
| pjmlp wrote:
| CUDA compilers are a fork of LLVM.
| gavinray wrote:
| lol. just lol. first thought when I read that
| my123 wrote:
| They use LLVM, but without the Clang part. (even available to
| 3rd-party apps as NVVM, which currently takes in LLVM 7 byte
| code)
|
| Upstream Clang supports compiling CUDA code however.
| Koshkin wrote:
| I like their no-frills home page better. (Reminds me of
| Slackware's.)
| nikic wrote:
| Wow, these release notes are completely useless. Here are some
| actual highlights of this release:
|
| * LLVM no longer assumes forward progress by default. This means
| it no longer miscompiles infinite loops in non-C++ programming
| languages.
|
| * LLVM now tracks applicability scopes for scoped noalias
| metadata. This means LLVM no longer miscompiles code for
| languages with high-quality aliasing information.
|
| * Dead store elimination now uses MemorySSA, and can eliminate
| dead stores across basic blocks.
| tambre wrote:
| People rarely seem to add release notes for their changes and I
| don't think anyone goes back at the end of the release cycle
| and picks out the highlights.
|
| For C++ features you also might be better off looking at
| cppreference.com [0].
|
| [0]: https://en.cppreference.com/w/cpp/compiler_support
| api wrote:
| I thought I was the only one with a git repo full of comments
| like "now with less bugs!"
| MrMorden wrote:
| Ser Davos has some thoughts about your comment.
|
| http://gph.is/2vGAqYf
| a_e_k wrote:
| Davos learned that from Stannis.
|
| https://www.youtube.com/watch?v=G0zNWswcqMg
| aaronbrethorst wrote:
| "Now with different bugs!"
| dhosek wrote:
| Except this is about llvm and not clang. C++ features don't
| come into play with llvm since it's the middle step between
| the high-level compilation of the language and the writing
| actual machine code for the target architecture.
| mshockwave wrote:
| * LLVMBuild is removed. This means most of the building works
| are handled by CMake now
| myrmidon wrote:
| > This means LLVM no longer miscompiles code for languages with
| high-quality aliasing information.
|
| This affects Rust, for instance, and might net 0-5% better run-
| time performance: https://github.com/rust-
| lang/rust/issues/54878#issuecomment-...
| throwaway894345 wrote:
| In general I would be very curious to know more about the
| bugs, etc in LLVM which would benefit Rust. I'm of the
| impression that there are many because LLVM is so over-fitted
| to the C++ ecosystem, but I don't know much about them in
| particular.
| mrec wrote:
| The `A-LLVM` issue label is probably a good starting point.
|
| https://github.com/rust-lang/rust/labels/A-LLVM
| nindalf wrote:
| If you're looking for someone to ask, the expert is nikic,
| author of the grandparent to your comment. They have worked
| on many of these specific improvements in LLVM, from which
| Rust has benefited.
| bla3 wrote:
| You're saying the person complaining about the release
| notes is one of the people who wrote the release notes?
| :-D
| adrian17 wrote:
| > Dead store elimination now uses MemorySSA, and can eliminate
| dead stores across basic blocks.
|
| I thought it wasn't enabled by default in 12? I recall this
| being said at some point.
|
| That said, I do appreciate this change making it into Rust, as
| it very visibly improves how it handles moving big structs
| around.
| nikic wrote:
| The change you have in mind is MemorySSA-based memcpy
| optimization, which is indeed not enabled in LLVM 12 (but is
| enabled in Rust).
| adrian17 wrote:
| ...oh, yeah, I saw "now uses MemorySSA" and immediately
| thought of the memcpy optimization pass, without carefully
| reading the entire comment - my bad.
___________________________________________________________________
(page generated 2021-04-16 22:02 UTC)