[HN Gopher] LLVM 16.0.0 Release
___________________________________________________________________
LLVM 16.0.0 Release
Author : mfiguiere
Score : 94 points
Date : 2023-03-18 18:04 UTC (4 hours ago)
(HTM) web link (discourse.llvm.org)
(TXT) w3m dump (discourse.llvm.org)
| camel-cdr wrote:
| Notably, function specialization optimization has been finally
| enabled by default, although it still seems to only be capable of
| constant propagating variables of register size [1].
|
| The heuristics are, understandably so, somewhat conservative [2],
| and I presume there are some projects that could benefit from
| enabling `-mllvm -funcspec-for-literal-constant`, raising `-mllvm
| funcspec-max-clones=3` ad lowering `-mllvm -funcspec-min-
| function-size=100`.
|
| [1] https://godbolt.org/z/jKo7K3jPd
|
| [2] https://github.com/llvm/llvm-
| project/blob/main/llvm/lib/Tran...
| pitaj wrote:
| I wonder if function specialization will help Rust, C++, etc as
| much as it will benefit C.
| charcircuit wrote:
| The notable changes for me are faster linker times and C++17
| (gnu++17) now being the default standard used.
| TwentyPosts wrote:
| Any idea of how much faster we're talking here?
| charcircuit wrote:
| Around 10% faster.
|
| In D130810 the speedup is given as:
|
| Performance linking some programs with --threads=8 (glibc
| 2.33 malloc and mimalloc):
|
| - clang: 1.05x as fast with glibc malloc, 1.03x as fast with
| mimalloc
|
| - chrome: 1.04x as fast with glibc malloc, 1.03x as fast with
| mimalloc
|
| -internal search program: 1.08x as fast with glibc malloc,
| 1.05x as fast with mimalloc
|
| In D133003 the speedup is given as:
|
| Speed-up with mimalloc and --threads=8 on an Intel Skylake
| machine:
|
| - clang (Release): 1.27x as fast
|
| - clang (Debug): 1.06x as fast
|
| - chrome (default): 1.05x as fast
|
| - scylladb (default): 1.04x as fast
|
| Speed-up with glibc malloc and --threads=16 on a ThunderX2
| (AArch64):
|
| - clang (Release): 1.31x as fast
|
| - scylladb (default): 1.06x as fast
| asb wrote:
| I've written up a tour of some of the RISC-V related changes in
| the LLVM 16 development cycle https://muxup.com/2023q1/whats-new-
| for-risc-v-in-llvm-16
| badsectoracula wrote:
| AFAIK the original Clang 15 broke a lot of software, including
| pretty much all "configure" scripts generated by Autoconf due to
| some default options[0] that treated some of the code used for
| various feature checks invalid and the end result was checks
| failing even though they should have passed - often with barely
| any notification to the user (the user would see a "no" instead
| of a "yes" in some check). This was reverted in 15.0.1 but that
| was only to give people time to update until Clang 16 was
| released, the Clang developers wanted to get ahead with the
| change regardless and expected upstream developers to fix their
| code (this includes not only configure scripts but also projects
| using old style code - and AFAIK it wasn't only Autoconf that
| made such tests, though the focus was on it).
|
| The problem however is that thousands of projects that still
| haven't updated. Gentoo developers are trying to patch the
| packages but as can be seen in [1] that tracks all the relevant
| bugs, not even half of them are fixed. Also those are fixes in
| Gentoo - AFAIK while the Gentoo devs are trying to upstream their
| patches, not everything is patchable. Note that i mention Gentoo
| since they were the ones that showed up in the discussions i've
| seen, but the same is case with all distributions (and projects
| like Homebrew, etc) - it is just that most likely Gentoo users
| were affected the most as they build everything from source and
| can use Clang for that.
|
| But there seems to be two additional issues with Autoconf
| specifically (remember that this isn't just about Autoconf, it is
| just that due to how the existing Autoconf checks were written,
| configure scripts generated by it are the most likely to
| encounter the issue):
|
| The first is that while there have been fixes for the failing
| checks, there hasn't yet been a new release of Autoconf that uses
| these checks - when i run a freshly regenerated configure scripts
| on my PC with the latest stable release as provided by my
| distribution i still get the failing checks if i force Clang 15
| to use the options that were previously disabled. This means that
| any configure scripts generated _right now_ will fail when those
| become enabled again.
|
| The second is that some widely used macros in Autoconf[2], those
| to find if a library exists and to find which library exposes a
| symbol (e.g. if libm is needed to be linked to access the
| functions in math.h or they are part of the standard library -
| different OSes still need different options here) do it by
| writing and attempting to link a small C program that defines the
| function as (IIRC) "char the_function_name();" with code that
| calls that function (the function is not actually called, the
| check only tries to compile and link that program) and if that
| fails it assumes the library does not exist / does not support
| the function. Problem being is that the above fails with Clang
| 15.0.0 because of the "()" part (should have been "(void)" but
| when the check was written many years ago it was meant to work
| with pre-C89 compilers that didn't support the void keyword).
| This is fixed in Autoconf now but as mentioned above, no release
| yet so any currently made brand new configure script will have
| this check failing. But the more important issue is that this
| check seems to be a ticking bomb - at least as far as Clang is
| concerned - since it can trigger various errors in the future and
| judging from the responses by one of the Clang developers[2] (i
| actually recommend reading the entire thread) they seem to be of
| the opinion that treating this as an error in the future is
| something they might do as it is technically UB. As of right now
| there hasn't been any fix for this and from the discussions from
| that thread, the Autoconf developers do not seem to be able to
| figure out a generic solution (the only solution they found is to
| include prototypes for all known libc functions but this wont
| work if you, e.g., want to figure out if the system has curses or
| ncurses - as an example NetBSD needs -lcurses not -lncurses, at
| least last time i checked). So even if a new Autoconf release is
| made now, the configure scripts might still break in the future
| if Clang developers decide to make this an error (AFAIK even
| without a release some distros have patched Autoconf to fix the
| errors introduced and reverted in Clang 15.0.0 but even those do
| not have a fix for the above).
|
| Also all these are about freshly generated configure scripts, in
| practice there are projects out there where their configure
| scripts haven't been regenerated for a long time (often because
| there hasn't been a new release for a long time). Though many of
| them can be brought up to date with "autoreconf -fi", assuming of
| course the fixes i mentioned above are available.
|
| (FWIW from what i can tell this isn't a problem with GCC and the
| devs contemplated adding a special check for Autoconf generated
| code to skip the errors if they decide in the future to make
| these errors, but of course this only affects Autoconf - while i
| focus on it, Autoconf isn't the only affected program - and
| regardless the entire point of Autoconf is to allow whatever
| compiler and tools there are around instead of requiring specific
| ones from the user)
|
| Considering the above i wonder if Clang 16 decided to proceed
| with the changes regardless. The release notes do mention some
| changes that might affect configure scripts[4] but i'm not sure
| if the notes there are just some heads up for people making
| configure scripts to check for potential breakage in the future
| or honeyed words for "technically not _every_ configure script
| will break, so hey, we warned you ". This is a bit amusing since
| if you check in the discussions i linked to, a concern others had
| was that the release notes in the version of Clang 15 barely made
| a mention of the potential for breakage.
|
| (as a side note, all the above focus on Autoconf might sound like
| me ragging on Autoconf/Autotools, but this wouldn't be farther
| from the truth - having built a lot of software from source code,
| including on minimal non-Desktop non-Linux Unix-like environments
| like NetBSD, i absolutely _love_ that Autotools-based releases do
| not require anything that isn 't already there in a Unix-like
| environment to work and even recently decided to use it for some
| of my own projects because of that, which is how i found all the
| above. From a practical perspective it isn't that hard to work
| around the issues even with existing configure scripts - AFAIK
| some of Gentoo patches do exactly that - so despite all the above
| it is still my favorite build system to build stuff with as a
| _user_... as a developer, well, i haven 't found it to be any
| worse than other build systems)
|
| [0] https://discourse.llvm.org/t/configure-script-breakage-
| with-...
|
| [1] https://bugs.gentoo.org/870412
|
| [2] https://www.gnu.org/savannah-
| checkouts/gnu/autoconf/manual/a...
|
| [3]
| https://lists.gnu.org/archive/html/autoconf/2022-11/msg00006...
|
| [4]
| https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNot...
| charcircuit wrote:
| I would call this a design flaw with autotools. It would be
| ideal if you only had to update autotools to work around this.
| But it seems like autotools brittle configure scripts are
| spread out between thousands of projects instead of a single
| place. The amount of brittle code should be minimized and
| easily updatable.
| diimdeep wrote:
| Is it slower again ? [1]
|
| [1] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
| akvadrako wrote:
| Yeah, LLVM is a dog, about twice as slow and GCC and 20 times
| slower than TCC: gcc-11.2 -O0 0.02
| clang-12.0.1 -O0 0.04 tcc 0.002
|
| I wish TCC was still being maintained and supported by modern
| toolchains.
|
| [1]: https://forum.nim-lang.org/t/8677
| camel-cdr wrote:
| What makes you thing TCC isn't maintained anymore?
| w-m wrote:
| https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.htm...
|
| From the article:
|
| _I think this is the first time in quite a few releases where
| we end up with an overall regression. However, the situation is
| not quite as bad as it looks.
|
| In particular, the large regression on the right is due to
| enabling C++17 by default. The close to two times slowdown in
| 7zip O0 builds comes down to STL headers becoming 2-3 times as
| large in C++17.
|
| While this is sad, and I had to edit out some choice words on
| the C++ standardization committee (I hear that this gets even
| worse in C++20), at least this does not affect non-clang
| compilers (e.g. Rust) and C code._
| jahnu wrote:
| Am I blind or is there still no proper/full PMR implementation?
| :(
| amir734jj wrote:
| What is a good llvm book, not a beginner level?
| weitzj wrote:
| Xtensa support (esp32). Will be interesting how this will be for
| Rust and Zig support for esp32
|
| https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
|
| https://www.phoronix.com/news/LLVM-Xtensa-Backend
|
| https://github.com/espressif/llvm-project/issues/4#issuecomm...
|
| https://github.com/ziglang/zig/issues/5467#issuecomment-1465...
| jws wrote:
| I see that after 50 years, C has finally gained an _official_
| null pointer value and type! "nullptr" and "nullptr_t".
|
| That wouldn't be so interesting, but it highlights the complexity
| of specifying a language and implementing a specification. For
| what sounds at first hearing a lot like "#define nullptr 0" the
| Clang release notes identify 7 syntactic cases where the C
| standard and the C++ standard disagree about whether "nullptr"
| should be acceptable in a location. Clang takes each side about
| equally and it sounds like they are waiting for the standards
| groups to fix the standards.
| pmarin wrote:
| It's a very common pattern to memset to zero structs with
| pointers to initialize them. What happend now with this new
| "feature"?
| camel-cdr wrote:
| Nothing changes. memseting a struct to zero has always been
| and still is implementation defined behavior, as there are no
| guarantees on the bit representation of a null pointer. [1]
|
| The C11 standard says that a null pointer constant is defined
| as follows: "An integer constant expression with the value 0,
| or such an expression cast to type void _, is called a null
| pointer constant. "
|
| The new definition is: "An integer constant expression with
| the value 0, such an expression cast to type void _, or the
| constant nullptr are all a null pointer constant."
|
| The reason for adding nullptr, is because NULL is roughly
| defined as a macro that expands to "0" or "(void*)0". This
| causes trouble with the addition of type detection trough
| _Generic and now typeof.
|
| [1] https://c-faq.com/null/machnon0.html
| dotnwat wrote:
| Very excited about this release. Just tried out clang-format on a
| code base with a lot of concepts, and finally, the formatting
| looks great.
| ianlevesque wrote:
| It's not a headlining feature but I love clang-format. Fast and
| reasonable output choices.
___________________________________________________________________
(page generated 2023-03-18 23:00 UTC)