[HN Gopher] LLVM 13.0
___________________________________________________________________
LLVM 13.0
Author : Tomte
Score : 134 points
Date : 2021-10-05 15:22 UTC (7 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| jedisct1 wrote:
| Nightly versions of Zig now include LLVM 13.0.0.
|
| So you can already use it to easily compile and cross-compile
| code (Zig, but also C and C++) to many targets including
| WebAssembly and Apple Silicon, using LLVM 13.
| boris wrote:
| How about an equivalent for Clang targeting the MSVC runtime
| (which is how both Google and Mozilla build their web browsers
| for Windows), is this supported?
| jcelerier wrote:
| I use the llvm-mingw (targeting ucrt) for that, it's
| available on GitHub and has been updated to 13
| rofrol wrote:
| I googled what is ucrt
|
| - https://github.com/MicrosoftDocs/cpp-
| docs/blob/master/docs/p...
|
| - https://stackoverflow.com/questions/57528555/how-do-i-
| build-...
| gavinray wrote:
| How can you use Zig to compile C++? This isn't one I was aware
| of
| SloopJon wrote:
| There's a blog post that describes this:
|
| https://andrewkelley.me/post/zig-cc-powerful-drop-in-
| replace...
|
| HN discussion:
|
| https://news.ycombinator.com/item?id=27872596
|
| previous discussion:
|
| https://news.ycombinator.com/item?id=22679138
| gavinray wrote:
| I know of "zig cc" -- the same article says:
| There are some follow-up issues related to zig cc which are
| still open: - ... - support compiling and
| linking c++ code
|
| Did this change recently? I've tried "zig cc" for C++
| before and asked on the Discord and was told it wasn't
| capable of it. rayga@DESKTOP-88A51E5
| MINGW64 ~/Projects/tmp/zig-cc-test $ zig version
| 0.9.0-dev.959+f011f1393 rayga@DESKTOP-88A51E5
| MINGW64 ~/Projects/tmp/zig-cc-test $ zig cc test.cpp
| test.cpp:1:10: fatal error: 'iostream' file not found
| #include <iostream> ^~~~~~~~~~ 1 error
| generated. rayga@DESKTOP-88A51E5 MINGW64
| ~/Projects/tmp/zig-cc-test $ clang test.cpp
| rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/zig-cc-test
| $
| kristoff_it wrote:
| you need to use `zig c++` to compile cpp code
| RcouF1uZ4gsC wrote:
| Looking at the release notes for Clang, there are no new C++20
| features. Clang is really falling behind GCC and even Microsoft
| Visual C++ with regards to C++20 implementation.
|
| https://en.cppreference.com/w/cpp/compiler_support/20
| cracauer wrote:
| Sadly format did not make it.
| Thev00d00 wrote:
| but we have fmtlib thank goodness
| google234123 wrote:
| Are many of the C++20 features even ready for prod? ranges,
| concepts, modules...?
| pjmlp wrote:
| https://en.cppreference.com/w/cpp/compiler_support/20
| Koshkin wrote:
| GCC FTW
| zauguin wrote:
| According to clang's C++20 status list, clang 13 adds `using
| enum`, more implicit moves and partial support for lambdas in
| unevaluated contexts.
| cute_boi wrote:
| also it doesn't support many hardware compared to gcc and
| people seem to be more crazy about it idk why :(
| h2odragon wrote:
| Things like this will win fans:
| https://blog.matthieud.me/2020/exploring-clang-llvm-
| optimiza...
| nsajko wrote:
| It's not just modern C++ support. C/C++ implementations mostly
| get taken for granted, but taking a look at the LLVM bug
| tracking is horrifying - there are huge amounts of years-old
| reports that nobody seems to be working on even though they're
| serious. Even things like valid C++ code failing to compile
| because Clang fails to parse it, if I remember correctly.
|
| I don't have a point with this other that it's surprising (for
| end-users like me). Also, I'm not sure how GCC compares.
| mlvljr wrote:
| Now you might have a better idea, with the downvotes.
|
| :)
| woodruffw wrote:
| > Also, I'm not sure how GCC compares.
|
| Not favorably. Both projects have massive "backlogs," by
| naive metrics.
|
| Maintainers for both are in a double bind: people get mad
| when you close their years-old issues because they can't be
| reproduced anymore, and people give you grief for not closing
| issues.
| pjmlp wrote:
| The two main backers (Apple and Google) seem to have backed
| out.
|
| From my point of view, for Apple, their use of C++, C++17 is
| good enough.
|
| Metal uses a C++14 dialect as shading language, IO and
| DriverKit an embedded friendly subset, for everything else
| there is Objective-C and Swift.
|
| Google seems to have been put off by losing the ABI vote and
| changed focus into Abseil instead, and have their own Draconian
| style guide anyway.
|
| And are increasingly adopting Rust as well.
|
| Intel, ARM, IBM, Sony, Nintendo will have to jump in.
|
| By the way, concepts were mostly implemented by a single guy!
| mwcampbell wrote:
| It surprises me, though, that GCC is ahead (assuming the GP
| is correct). Anyone here know who's driving C++20 support in
| GCC?
| pjmlp wrote:
| Red-Hat mostly.
| rnd0 wrote:
| Oof. Anyone else worried about the amount of GNU
| infrastructure (GCC, GLibc, etc) that has fallen into
| IBM's hands -and what will happen with it in the future?
| pjmlp wrote:
| Well, IBM among others, provided the initial money to
| make Linux relevant anyway.
|
| > Commercial use began when Dell and IBM, followed by
| Hewlett-Packard, started offering Linux support to escape
| Microsoft's monopoly in the desktop operating system
| market
|
| -- Wikipedia
| rnd0 wrote:
| Linux isn't GNU, and there have been a rise of projects
| that prove exactly that.
|
| If we reach the point where redhat pulls the cash out
| from GNU then there's a lot of infrastructure that will
| be lost. I find it alarming that no one ever seems to
| mention that.
| dralley wrote:
| Perhaps people should worry less and contribute more, to
| prevent such concerns from becoming problems in the first
| place.
|
| If your company is making use of Linux, GCC, OpenSSL and
| so forth, they should be setting aside some engineering
| resources to contribute to those projects, especially if
| they aren't paying a corporate vendor like RH, SUSE, or
| Canonical to do it on their behalf.
|
| Naturally, the "tragedy of the commons" is that everyone
| wants to take advantage of free software while
| contributing back as little as possible, usually while
| simultaneously complaining or handwringing about those
| that _are_ actually contributing.
|
| Why is it that this conversation has turned from Apple
| and Google, with a combined market cap over 4 trillion
| dollars _pulling_ their resources from these foundational
| projects, to handwringing that Red Hat, with a 125x
| smaller valuation might pull their resources from GNU,
| something there is no indication of happening? Surely the
| focus ought to be in the other direction...
| jabl wrote:
| > Intel, ARM, IBM, Sony, Nintendo will have to jump in.
|
| Intel and IBM have recently announced their own proprietary
| LLVM-based compilers, but they seem more interested in
| backend work to make their own CPU's look good [1] than
| spending resources on frontend work. I guess that applies to
| ARM as well.
|
| Sony and Nintendo are, I guess, mostly satisfied? They just
| want a decently good compiler and toolchain ecosystem, but
| for games most performance comes from the GPU anyway, chasing
| low-single-digit performance increases for CPU code doesn't
| seems like a super good investment opportunity for a game
| console company.
| nerdponx wrote:
| Is it possible that they're making lots of internal
| improvements and not upstreaming them?
| pjmlp wrote:
| Definitely, Sony for example doesn't upstream stuff that
| might reveal architecture details that could help piracy.
|
| There are a couple of talks from them at some LLVM
| summits.
| boris wrote:
| > The two main backers (Apple and Google) seem to have backed
| out.
|
| This highlights an important difference between GCC and LLVM
| that many fans of the latter seem to miss: LLVM is first a
| bunch of compiler components that Apple and Google use for
| their own needs and a C/C++/etc compiler for you and me
| second and only as long as it flows naturally from the first.
| While GCC is a C/C++/etc compiler, that's the end-goal.
| volta83 wrote:
| The people working on GCC are also mostly paid by
| companies, e.g., like Red Hat. The moment these companies
| back out, the same thing will happen to GCC.
|
| The root of the problem is that very few people find it
| "FUN" to implement C++ compilers on their free time, so
| these open source projects live from companies for
| contributions.
| bluescarni wrote:
| No.
|
| GCC existed and thrived long before companies started
| putting money into it. It would clearly suffer if, e.g.,
| Red-Hat withdrew its support, but not nearly as LLVM
| would in the same situation.
|
| The culture, history and governance of the two projects
| are very different and they do matter.
| dxf wrote:
| >The two main backers (Apple and Google) seem to have backed
| out.
|
| Google has not "backed out".
|
| E.g. look at this topic's discussion thread. The current top
| comment is about [[clang::musttail]]; the implementor of that
| attribute works for Google. The current second top comment is
| about the Rust compilation wins from the switch to the New
| Pass Manager; the NPM was primarily implemented by (and
| turned on as the default pass manager upstream) by people who
| work for Google. Google is actually growing our investment in
| people contributing to core Clang/LLVM.
|
| Source: I am a manager for C++ toolchains (those that target
| production, Chrome, ChromeOS) at Google.
| pjmlp wrote:
| From the point of view from C++20 support it definitely
| looks like that from the outside.
|
| Which you pretty much confirmed by giving examples
| completely unrelated to ISO.
|
| How is that migration to C++20 modules support going?
| dxf wrote:
| If you are asking, "Is Google helping with any C++20
| support upstream?" the answer is Yes.
|
| E.g. for standard concepts in libc++:
|
| std::derived_from (D74292) std::convertible_to (D77961)
| Arithmetic concepts (D88131) std::move_constructible
| (D96230) std::copy_constructible (D96232) std::invocable
| (D96235) std::regular_invocable (D96235) etc.
|
| Google is _big_ and C++ is used for many projects that
| build with disparate toolchains (even if they are all
| based on Clang/LLVM); each project can have different
| needs to adopt parts of C++20 sooner than the others, and
| different costs for doing so. Moving from Clang modules
| to C++ standard modules is an effort that, for some of
| our projects, lives at the nexus of "Are Standard Modules
| sufficiently done upstream to be able to replace our use
| of Clang modules?" and "What is the cost of doing that?"
| and "What is the benefit of making that switch?" For
| other projects, adopting standard modules is a more
| straightforward calculus.
| nicoburns wrote:
| This will be included in the next Rust release and seems to
| contain some nice compile time wins. Pretty much 10% faster
| across the board for most Rust crates:
| https://www.reddit.com/r/rust/comments/pxvcy4/ryan_levick_th...
|
| EDIT: The new pass manager which improved the compile times is
| not scheduled to be enabled until Rust 1.57 (the release after
| the next one).
| runevault wrote:
| I was a little bummed to see the pass manager being held back.
| I wish there was a flag you could pass to rustc to go ahead and
| use it now while only making it the default in 1.57 (or at
| least I haven't heard of being able to do that).
| haberman wrote:
| I'm excited for the release of [[clang::musttail]], an attribute
| that I implemented to bring guaranteed tail calls to C, C++, and
| Objective-C:
| https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNot...
|
| I talked more about some performance motivation for this feature
| here: https://blog.reverberate.org/2021/04/21/musttail-
| efficient-i...
| ndesaulniers wrote:
| I worry whether LLVM can actually provide such guarantees ATM.
|
| https://reviews.llvm.org/D107872 makes me doubt.
| haberman wrote:
| Yes I think there are some bugs to be worked out still. I
| implemented Clang's [[clang::musttail]] attribute on top of
| the existing LLVM "musttail" attribute, but it does appear
| that there are some issues with the existing attribute at the
| LLVM level.
|
| In addition to the bug you mentioned, there are a few
| architectures where musttail is not supported supported. The
| POWER backend (big endian or pre-POWER10) and ARM backend
| (32-bit only) will throw errors for musttail in the backend.
|
| In the long-term though, I see this being a solid foundation
| on which to build. x86/x64/ARM64/POWER10 all support it. All
| the architectures seem to be going in a direction where this
| is possible to guarantee. Hopefully the bugs will get ironed
| out over time. Thanks for your bugfix on this!
| google234123 wrote:
| Welcome to the future of C++ :) [[clang::musttail]]
| [[deprecated]] [[nodiscard]] static inline bool& func(...)
| noexcept {...}
| wahern wrote:
| I'm more of a C programmer, not C++, but several years
| ago I switched to BSD/KNF style for function definitions
| because it improved consistency and diff-friendliness
| when managing qualifiers and attributes. BSD/KNF style
| is, int foo(int a, int b) {
| ... }
|
| This lends itself to prepending and appending qualifiers
| as separate lines, like
| __attribute__((unused)) __attribute__((format
| (printf 1, 2))) static inline char *
| sformat(const char *fmt, ...) { ...
| }
|
| Often I'll split linkage qualifiers (static inline) from
| return type (char *), especially when linkage is
| controlled by a macro.
|
| K&R and Linux styles are similar: int
| foo(int a, int b) { ... }
|
| Function prototype styles are the same across BSD/KNF,
| K&R, and Linux, keeping the return type on the same line
| as the identifier, but I'll often put linkage qualifiers
| and sometimes even return types on their own line,
| especially if there are other attributes as well.
|
| Note: All these styles normally place braces on the same
| line as control flow statements. Function definitions are
| treated differently for what I understand in hindsight
| are good (if possibly serendipitous) reasons.
|
| C++ complicates things with methods, template, etc, so
| I'm not sure how well the above styles fit C++. In what
| little C++ I've written one of my first gripes was with
| difficulties controlling linkage, period.
| ufo wrote:
| To be pedantic... the musttail attribute goes in the
| return statement with the function call, not on the
| function definition.
| ndesaulniers wrote:
| [[always_inline (for real though this time)]]
| vlovich123 wrote:
| Attributes don't need to go in separate sections though:
| [[clang::musttail, deprecated, nodiscard]].
|
| Also unfortunately the inline keyword doesn't really do
| much except make the author feel happy they thought the
| compiler they told it to inline that function.
| Matheus28 wrote:
| You forgot constexpr
| sitkack wrote:
| CppCon 2017: Ben Deane & Jason Turner "constexpr ALL the
| Things!" https://www.youtube.com/watch?v=PJwd4JLYJJY
| ndesaulniers wrote:
| > The POWER backend (big endian or pre-POWER10) and ARM
| backend (32-bit only) will throw errors for musttail in the
| backend.
|
| Hopefully it's just a bug in those backends, and not that
| the C++ standards committee ratified something that's
| impossible to support on certain architectures.
| haberman wrote:
| I don't believe musttail has been considered by the C++
| standards committee, has it? Right now the Clang
| attribute is a Clang-only non-standard extension.
|
| I believe the backend issues mostly center around DSOs. I
| am hoping that the dso_local attribute can help out here:
| https://llvm.org/docs/LangRef.html#runtime-preemption-
| specif...
|
| If musttail only works for functions within the same DSO,
| that seems sufficient.
| sitkack wrote:
| Wow! This is amazing, you are amazing. Thank you!
| klaussilveira wrote:
| Kaleidoscope is great to learn your way into LLVM:
| https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/LangI...
| tubby12345 wrote:
| Going through that tut literally this week and the docs are
| horribly out of sync with llvm itself. Solution is to check out
| 11.0 tag and to follow
|
| https://releases.llvm.org/11.0.0/docs/tutorial/MyFirstLangua...
___________________________________________________________________
(page generated 2021-10-05 23:01 UTC)