nikic

One problem here is that GCC emits certain warnings as part of the optimizer, which results in many false positives that are essentially impossible for the lay programmer to understand. For example, jump threading might duplicate some code path and propagate constants in it, and then warn about an uninitialized variable / out of range access / etc in that code-path, even though it does not exist in that form in the original program.

This has no relation to Clang's permissive license. The problem here is generally that nobody has implemented the necessary support, not that they have implemented support in their private forks but did not bother to upstream it. A GPL-style license doesn't magically force contributors to start working on a particular feature.

Google at least is one of the largest contributors to the LLVM project -- it's just that their contributions don't tend to focus on Clang frontend work.

As far as I know there isn't anything like that for cmovs. The cmov depends on the condition, so it will only be executed once the condition is available. Of course, execution can still continue with instructions that don't need the cmov result. And because there is no branch, which instructions get executed does not depend on the cmov condition.

LLVM recently introduced a SelectOptimize pass, which is used for select -> branch conversion in the presence of PGO information. This should replace the current non-PGO-aware X86 cmov conversion pass.

The result of this should be that without PGO cmov is preferred, which is the right default (incorrectly picking a cmov is a bit worse than picking a branch, incorrectly picking a branch is catastrophically worse than picking a cmov).

For reference, here are the C++ support pages for GCC and Clang:

https://gcc.gnu.org/projects/cxx-status.html

https://clang.llvm.org/cxx_status.html

I don't see how the license is relevant here. It's not like companies have already implemented full C++20 support in their local forks and just haven't bothered upstreaming it.

But yes, a lot of LLVM users don't care about C++ standard compliance at all, for example because they don't use C++.

This is what I get locally:

    time php fib.php 42
    23s

    time python3 fib.py 42
    1m1s

I suspect that you're doing something very wrong, like running PHP with an active debugger or similar.

If we're talking in comparison to slow interpreted languages like Python, then function calls in PHP are not particularly expensive. Debuggers can make them quite expensive though.

Edit: Just to note, PHP's execution time drops to 4s with enabled JIT.

It's hard to check whether old opcache bug reports have been resolved, because these issues tend to be non-reproducible. It's quite likely that they are, as opcache is tested much more extensively now than it was a few years ago. Back then, the file cache had essentially no automated tests, while nowadays we check our test suite with all four file cache combinations (written with/without SHM, read with/without SHM).

Restarts are an area that still doesn't have much in terms of automated tests, but at least it's covered by fuzz testing.

The change you have in mind is MemorySSA-based memcpy optimization, which is indeed not enabled in LLVM 12 (but is enabled in Rust).

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.

FWIW, the two people who are paid to work on PHP (Dmitry and myself) both only work on the PHP implementation and not other parts of the project (infra, websites etc). The infrastructure is maintained entirely by volunteers.

I am personally not qualified to do infrastructure maintenance, knowing next to nothing on the topic.

As we don't really know, we went with the worst-case assumption. If it's wrong, then at least it was a nice excuse to update some old infrastructure :)

For now I'm only handling people for which I recognize the account or can confirm recent commits.

An important factor here is hardware access. Tier 2 targets just produce cross-compilation artifacts, tier 1 targets require actual hardware to run on. For example, a tier 1 macos aarch64 target is impossible until the hardware can be run in CI, for every merge.

That was certainly a concern. When instrumenting PHP to detect where the behavior changes and testing various codebases, I found that this actually happens much more rarely than I would have anticipated in advance. We're talking like 2 occurrences in the test suite of major frameworks.

> I find it really weird that the match expression is strict comparison, but everywhere else it's loose comparison. Don't get me wrong, I prefer strict comparison, and prefer strongly typed languages because of it, I just feel that this is a strange design choice.

What is "everywhere else"? You usually explicitly need to specify the type of comparison you want by writing either == or ===. "switch" is a case where the comparison operator is implicitly "==". "match" using "===" instead is one of the primary reasons for introducing it.

> In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations.

The only change to "@" is that it no longer suppresses fatal errors, which was generally not an intended or useful effect. The only thing this affects in practice are error handlers that don't check for error suppression being active correctly.

The "@" operator is still very much needed for certain use-cases (e.g. I/O functions may throw expected warnings) and removing it was not even a remote possibility for PHP 8, and as such also not a candidate for the attribute syntax.

It is worth noting that PHP uses the same attribute syntax as Rust does.

PHP 8 has plenty of breaking changes (https://github.com/php/php-src/blob/08e6c209550a268500bbdef4...), mostly in the department of throwing errors more aggressively, and fixing some long-standing "features" (like 0 == "foobar" being true). But there's a budget to this, and you have to strike a balance between how much code you break and what benefit you get out it.

SIMD intrinsics are unsafe, because reaching a SIMD intrinsic not supported by the host CPU is undefined behavior (in practice usually SIGILL).

Choice of cmov vs branch is pretty tricky because profitability depends on branch probabilities, which are commonly not known. LLVM has an X86 cmov conversion pass that does this based on some cost modeling for loop-carried dependencies, but it does not always make the right choice. Common problem is binary search code where you really, really want that cmov, but might not get it.

If you build LLVM often, use the shared library build (BUILD_SHARED_LIBS=true). Most of the memory usage (and a large part of the time in incremental builds) comes from linking final artifacts if you do not use shared libraries.

As usual, things aren't quite that simple. While it certainly can happen that the compiler can pessimize carefully crafted SIMD code by applying undesirable transformations, simply not optimizing intrinsics would lead to other problems.

If you consider SIMD code that spans more than just one small function, then it is quite useful if the compiler can SROA (e.g. you pass around an array of vectors instead of having 8 arguments to each function, but still want them to end up in registers eventually), LICM (you're calling a function that needs a constant vector in a loop) or otherwise optimize your code.

If you want the compiler to leave alone your intrinsics, link in an assembly file.

Half the point of using SIMD intrinsics rather than embedding assembly is that register allocation and instruction scheduling are performed by the compiler. Using intrinsics certainly does not guarantee that exactly the corresponding instructions will be emitted in exactly the given order.

That sounds more like an implementation issue than a design issue. If you are using UTF-8 actual decoding into Unicode code points is not necessary for most operations and Rust will not do that.

It also does not imply that string operations may fail. String construction from raw bytes may fail, but otherwise the use of UTF-8 strings should not introduce additional failure conditions.

Rust updates LLVM more commonly than LLVM does stable releases, so it has been using a version somewhere between LLVM 6 and LLVM 7 for a while already.

I think one of the main areas that improved in LLVM 7 relative to LLVM 6 that Rust cares about is better support for WASM in LLD.

> Euler was the first person to realize this, afaik. Is there a term to describe these kind of "de-unit-ified" equations? More than once I've found myself needing to reconstruct a proper equation (with correct dimensions and constants) from one of these bastardized non-equations.

Not very surprisingly, it's called nondimensionalization (https://en.wikipedia.org/wiki/Nondimensionalization).

Seeing that `i % len` in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... makes me uncomfortable. This is performing a non-constant modulus on every loop iteration, which seems quite excessive even for a slow path. Performing wraparounds using a separate branch would be more efficient.

The only "dick move" involved here is the fact that zdnet wrote this article. Minor security issue lapses standard disclosure deadline? Who cares. Instead we get this attempt to sensationalize this into some kind of big Google vs. Microsoft rivalry.

Windows is an LLP64 platform, meaning that the "long" type on Windows stays at 32bit even when you're compiling 64bit binaries. Getting 64bit integer support for PHP on Windows took a major port of all basic type usage to move away from longs to custom types with a higher degree of control. I don't know whether or not this was a problem for Firefox or not.

Disclaimer: PHP core dev.

Be careful with microbenchmarks. From my experience, there tends to be very little correlation between performance improvements on microbenchmarks and real applications. If you improve performance on the microbench suite by a factor of two, you definitely will not get a factor of two on real applications -- more likely, it will be something like 2%.

Basically, if the benchmark is not testing end-to-end performance on Wordpress (or similar), then it's a useless benchmark.

Tangentially related, my number one feature request for GitHub would be support for cross-referencing (a la Opengrok) in the code browser. Browsing through project code without a local checkout is one of the main things I do on GitHub, but it's not very ergonomic without cross-referencing. (I also realize that this is much to ask for, considering how much time Opengrok takes to index large codebases.)