[HN Gopher] LLVM 11.0
___________________________________________________________________
LLVM 11.0
Author : zmodem
Score : 161 points
Date : 2020-10-12 11:54 UTC (11 hours ago)
(HTM) web link (releases.llvm.org)
(TXT) w3m dump (releases.llvm.org)
| einpoklum wrote:
| A few items from the release notes that caught my attention:
|
| * The debug information now has a feature which lets your
| debugger recover the value of an optimized-out value in certain
| (common) circumstances. I wish gdb and lldb pick on up this
| quickly and that it doesn't need you to specify anything
| explicitly.
|
| * If you're doing JITing with LLVM, you can now run your code's
| static initializations (which apparently you couldn't before? :-O
| )
|
| * Lots of RISC-V-related work (features, optimization
| improvements and bug fixes).
|
| * Nothing new for PTX (the CUDA IR which you can use LLVM to
| generate).
| DoofusOfDeath wrote:
| > The debug information now has a feature which lets your
| debugger recover the value of an optimized-out value in certain
| (common) circumstances. I wish gdb and lldb pick on up this
| quickly and that it doesn't need you to specify anything
| explicitly.
|
| It drives me nuts when I compile code with "-ggdb -gdwarf-4
| -O0" and gdb _still_ reports some symbols as "optimized away".
| I hope the bullet point above refers to this.
| xxpor wrote:
| I can't say I've ever seen that (I still use dwarf 3
| however). Is there a certain pattern to it?
| jmorse2 wrote:
| It's DWARF-5 only: variable values can be expressed in
| terms of a parameters value on entry to the function.
| Depending on the circumstances, that value can be recovered
| from further up the stack frame.
|
| (Ninja edit: although tuning for GDB might coax LLVM to
| emit the pre-standardised form, without DWARF-5).
| DoofusOfDeath wrote:
| I don't recall. Sometimes doing a full rebuilt takes more a
| while, so my process goes something like this:
|
| 1) build with "-O0 -ggdb"
|
| 2) In a debug session, notice that a variable I want to
| inspect has supposedly been optimized away. Get extremely
| frustrated.
|
| 3) Rebuild with every debug-friendly flag I can conceive of
| "-O0 -ggdb -fno-inline -gdwarf-4 -fno-omit-frame-pointer
| ..."
|
| 4) IIRC, step 3 usually (but not always?) addresses the
| issue.
|
| But long story short, I don't think I've ever pinned down
| the minimal requirements for avoiding the issue. Usually
| when I encounter this, I have bigger issues to deal with.
| sroussey wrote:
| For more details, see the specific release notes:
|
| https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html
| https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNot...
| https://releases.llvm.org/11.0.0/tools/clang/tools/extra/doc...
| https://releases.llvm.org/11.0.0/tools/flang/docs/ReleaseNot...
| https://releases.llvm.org/11.0.0/tools/lld/docs/ReleaseNotes...
| https://releases.llvm.org/11.0.0/tools/polly/docs/ReleaseNot...
| https://releases.llvm.org/11.0.0/projects/libcxx/docs/Releas...
| stabbles wrote:
| Are there any benchmarks that show compilation times using LLVM
| 11 versus older versions for representative projects?
| gjasny wrote:
| Our internal mono-repo with about 11000 C++ compilation units
| took about the same time with clang-11 compared to clang-10. I
| used the Ubuntu 20.04 packages from apt.llvm.org for testing.
| ChrisRackauckas wrote:
| Julia devs are posting things like: julia-
| master with llvm10: % julia-master --project=.
| --startup-file=no -e '@time using Plots' 4.028043
| seconds (6.51 M allocations: 470.491 MiB, 4.07% gc time, 16.62%
| compilation time) llvm11: % julia-master
| --project=. --startup-file=no -e '@time using Plots'
| 3.392166 seconds (5.97 M allocations: 431.075 MiB, 3.46% gc
| time, 17.22% compilation time)
|
| So it looks promising that the startup + compilation time is
| improved.
| CyberDildonics wrote:
| I wonder if cutting out a few million allocations might help
| wallnuss wrote:
| Julia is particularly sensitive to LLVM compile times. LLVM 11
| did improve those over LLVM 10 (which had noticeable
| regressions versus LLVM 9). As an example see
| https://github.com/JuliaLang/julia/issues/37915#issuecomment...
| kibwen wrote:
| I don't have a link on me, but I recall that Rust reported some
| improved compilation time from upgrading to LLVM 11 (which is
| the default for 1.47, released last week).
| faitswulff wrote:
| IIRC llvm 11 addressed a regression in compilation times.
| pjmlp wrote:
| > The macros enable users to write C/C++ Vector Length Agnostic
| (VLA) loops,
|
| What a great idea to use VLA to mean something else than it does
| for ISO C99.
| MaxBarraclough wrote:
| Relevant page:
| https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNot...
| formerly_proven wrote:
| Why not vector size agnostic?
| klodolph wrote:
| Because VLA already means "variable length array", which is
| confusing.
| jmc703 wrote:
| They're saying why not use "vector size agnostic" because
| that would be VSA instead of VLA, hopefully avoiding
| confusion.
| fizixer wrote:
| llvm is a bloated piece of ... mess ... built on a bloated
| language (C++) ...
|
| Avoid at all cost.
| sgillen wrote:
| Oh, good catch that's a big oof. I wonder if they were just
| unaware of this feature or what...
|
| I am excited for this feature though, naming aside.
| rudolph9 wrote:
| Is this sarcasm? I can't tell.
| young_unixer wrote:
| Yes.
| GolDDranks wrote:
| AVR is an official backend now. Rust has also recently added
| support for AVR.
|
| One more backend I'd like to see is the Espressif (ESP32 etc.)
| one. They've trying to upstream the support, but it seems that
| the lack of reviewers from the part of LLVM is slowing down the
| process...?
| black_puppydog wrote:
| I've been waiting for Espressif being upstreamed myself. I only
| arrived in the ecosystem about two months ago, but it has been
| absolutely _amazing_ to see the team work. And by that I mean
| the esp-rs group, but also the rust-embedded working group in
| general.
|
| They congregate on matrix and most "remote" companies could
| probably learn a bit or two about remote development from them.
| biggerfisch wrote:
| I was under the impression from reading the patch comments [1]
| that it was more of an issue with them not having an open copy
| of their ISA documentation (which then is causing a lack of
| possible reviewers)
|
| [1] https://reviews.llvm.org/D64830
| GolDDranks wrote:
| I stand corrected.
| tony wrote:
| Release notes:
| https://releases.llvm.org/11.0.0/docs/ReleaseNotes.html
| dang wrote:
| Changed to that from https://lists.llvm.org/pipermail/llvm-
| announce/2020-October/.... Thanks!
| zmodem wrote:
| I submitted the announcement email because it links to
| release notes from all the projects (i.e. Clang, LLD, Flang,
| etc.) and not just the main LLVM ones.
|
| (Also it seems the version number changed from 11.0.0 to
| 11.0?)
| dang wrote:
| That makes sense, but lists of links don't make good HN
| submissions, since there isn't much to discuss beyond the
| lowest common denominator of the items on the list. It's
| best to pick the most interesting element from the list and
| submit that--especially since HN is itself a list of links
| already. https://hn.algolia.com/?query=denominator%20list%2
| 0by:dang&d...
|
| (yes, we always do that with x.0.0 version numbers)
| gutino wrote:
| Anyone was able to use test Zig in Windows? last time i tried it,
| it compiled but i was not able to print a hello world. Thank you.
| sobeston wrote:
| It's been working great on windows for me for the last year or
| so. When did you last try it?
| azhenley wrote:
| The thing that caught my eye in the release notes is the blurb
| about Zig:
|
| _Zig is a general-purpose programming language and toolchain for
| maintaining robust, optimal, and reusable software. In addition
| to supporting LLVM as an optional backend, Zig links Clang and
| LLD to provide an out-of-the-box cross compilation experience,
| not only for Zig code but for C and C++ code as well. Using a
| sophisticated caching system, Zig lazily builds from source
| compiler-rt, mingw-w64, musl, glibc, libcxx, libcxxabi, and
| libunwind for the selected target - a "batteries included" drop-
| in for GCC /Clang that works the same on every platform._
| m4r35n357 wrote:
| Yep, that is a highly significant feature!
|
| https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
| Shoop wrote:
| I vouched for your comment but it looks like you may be
| shadow banned. Just an FYI -- you might want to email the
| mods, they're quite nice people.
| seg_lol wrote:
| What specifically, that they mention Zig or that you learned of
| Zig or that Zig has a lazy build system or ???
|
| The thing I really find interesting about Zig is the compile
| time function evaluation [1] and how it can stand-in for
| macros, code generation, precomputing values, etc. I think of
| CTFE as a continuation that comes baked into the binary from an
| earlier point in time, T-days_ago.
|
| As for this release, I am stoked to see Flang making progress.
| I am excited about Fortran in the browser.
|
| The interesting thing of note is that Zig is in the process of
| creating their own backend, but I don't see them dropping LLVM
| any time soon. An alternate backend is a great way to find bugs
| in codegen.
|
| [1] https://andrewkelley.me/post/zig-programming-language-
| blurs-...
| fpoling wrote:
| Zig's comptime is surprisingly powerful and does not suffer
| C++ template problem when an error message at the
| instantiation site is extremely unhelpful. And Zig managed it
| without constrains or traits just via bunch of useful
| compile-time operations on types. Still I do not see how one
| can have, for example, a struct field or enum case available
| only at certain compile-time condition like OS version.
| nikki93 wrote:
| You can put together an `std.builtin.TypeInfo` structure
| describing the type (eg. by using `@typeInfo` on an
| existing type and editing the result, adding something
| under `.Struct.fields`); then use `@Type` to 'unreflect' it
| back into a real type.
| fpoling wrote:
| Splendid! This is much more flexible than various static
| if aproaches like in D or modern C++.
| mhh__ wrote:
| I'm probably biased but _comptime_ doesn 't seem as elegant
| as the mechanism D provides for doing CTFE (i.e. I prefer a
| separation of quasi-template parameters)
| nikki93 wrote:
| Can you eg. generate a struct with fields based on an
| existing struct or on a comptime array in D? Can you
| receive a structure literal of anonymous type and iterate
| over it at compile time? (curious bc. these were a few
| things I found straightforward in Zig, and in C++ the main
| proposals involve tons of new metaclasses and reflection
| features for)
| mhh__ wrote:
| Yes to all points.
|
| D doesn't go the C++ route, the way code like this works
| is via generating new code (in text) at compile time
| which the compiler then compiles (duh) and replaces the
| _mixin_ statement within.
|
| Here's an annotated example of these features in use
|
| https://run.dlang.io/is/2b5zgC
| fithisux wrote:
| Brilliant.
| seg_lol wrote:
| _Aside_ , there no reason that this comment should be
| downvoted.
| renox wrote:
| While I agree that D is a 'treasure' (full of good ideas
| that should be copied more often by other languages) I
| don't understand why you think that D's way is better than
| Zig here.. What exactly do you prefer?
| mhh__ wrote:
| It's personal preference, but if a parameter is well and
| truly compile time I think it should be separate from the
| others (it certainly makes introspection "easier")
| throwaway17_17 wrote:
| Random question, but you're the first commenter who mentioned
| flang, so I am hoping you know the answer: is Flang doing its
| own alias management to enable Fortran's optimizations on
| arrays, or did LLVM finally regain usable alias attributes in
| the backend?
| seg_lol wrote:
| Perf isn't a high priority for me, more about getting
| Fortran into the browser. I don't have insights into the
| aliasing.
| throwaway17_17 wrote:
| That's interesting. Is it personal familiarity with the
| language that drives your desire or is some features of
| the language that you find lacking in alternative
| languages already in the browser space?
| drfuchs wrote:
| Zig's home-grown backend is strictly for super-quick
| turnaround compile and link during development. For optimized
| release builds, they'll depend on LLVM forever.
| jcelerier wrote:
| I've been building a similar toolchain which uses the same
| version of clang / libc++ / etc everywhere for my own software
| and things are so much more sane than trying to use
| GCC/libstdc++ on Linux, Clang/libc++ on macOS and MSVC on
| Windows which all have various behavior and performance
| divergence & pitfalls.
|
| CI still tests GCC and MSVC (except that MSVC of course has
| been ICE'ing on my project for the last six months), but all
| the releases are built with clang and my sleep quality has
| never been better :-)
___________________________________________________________________
(page generated 2020-10-12 23:00 UTC)