Facebook Planning To Ramp Up Investment In LLVM, Hire More Compiler Engineers

[ssokolow]

no, he didn't mean that. because 1) he has no clue and

Given what I've seen you posting in other threads, you have a much stronger claim to not having a clue than he does.

For example,

this circus of chasing slighly less ancient hardware is such a waste of resources. one would think redhat has engineers who are able to defer binding of codegen options to host cpu to install time or run time

(Long story short, if customers were willing to accept the install-time and QA implications of that, they'd be running Gentoo.)

2) it's not true most of the time

That depends on how you look at is. If you look at it as "one must always keep in mind what constraints the standardized features impose on the optimizer when maintaining its code", then it's always true. (And that's not even considering how much undefined behaviour that seems to work is floating around in the wild in C and C++.)

and 3) there's no connection to rust here

Where do you think the optimizers rustc uses come from? They were written for C and C++ and are still shared with Clang.

In fact, one of the long-running rustc bugs I remember best (rustc miscompiling infinite loops) is a direct result of LLVM's optimizers assuming that all languages have the forward-progress guarantee in the C++ spec.

[pal666]

Given what I've seen you posting in other threads, you have a much stronger claim to not having a clue than he does.

if you can't understand something, the most probable explanation is you are the clueless one

For example,



(Long story short, if customers were willing to accept the install-time and QA implications of that, they'd be running Gentoo.)

i'm aware of gentoo and i didn't suggest anything like it. i didn't suggest user-selectable options and local builds in particular

That depends on how you look at is. If you look at it as "one must always keep in mind what constraints the standardized features impose on the optimizer when maintaining its code", then it's always true.

well, no matter how vivid is your imagination, if feature doesn't generate code, it can't affect optimizer

(And that's not even considering how much undefined behaviour that seems to work is floating around in the wild in C and C++.)

new features certainly can't undefine defined behavior, it will break code. so they can only define undefined. some do, but it's rare and optimizers can take advantage only of other direction

Where do you think the optimizers rustc uses come from? They were written for C and C++ and are still shared with Clang.

lol, you can't stop, can you? rust compiler being written in c++ is number one point for uselessness of rust, but how in the hell "modern c++ features" can help optimization of rust code?

In fact, one of the long-running rustc bugs I remember best (rustc miscompiling infinite loops) is a direct result of LLVM's optimizers assuming that all languages have the forward-progress guarantee in the C++ spec.

this is rustc bug, which can be worked around by disabling optimizations. "working on c++ optimizers" could only make matters worse for buggy code

[ssokolow]

if you can't understand something, the most probable explanation is you are the clueless one

Exactly the principle that leads me to see you as the clueless one. I never said you were speaking nonsense. I said your arguments are based on flawed premises.

i'm aware of gentoo and i didn't suggest anything like it. i didn't suggest user-selectable options and local builds in particular

I referenced Gentoo because it's an object lesson in how much harder multiple build variants make QA... as well as a distro I used and liked for years.

well, no matter how vivid is your imagination, if feature doesn't generate code, it can't affect optimizer

A feature's specification can impose limitations on what the optimizer may do. If you don't agree with that, then you're so divorced from reality that there's no point in talking with you further.

new features certainly can't undefine defined behavior, it will break code. so they can only define undefined. some do, but it's rare and optimizers can take advantage only of other direction

My aside was that, sometimes, work on optimizers is done pessimistically to avoid the risk of breaking code they suspect to occur often and and can't disprove.

lol, you can't stop, can you? rust compiler being written in c++ is number one point for uselessness of rust, but how in the hell "modern c++ features" can help optimization of rust code?

Please take up an internally consistent position.

The rustc frontend is written in Rust, but it relies on LLVM for a backend because it's a mature solution.

Are you saying that C became useless when the GCC devs decided to join the LLVM devs in incorporating C++ into the compiler or are you arguing that the "rewrite large masses of perfectly good code in Rust" people are right?

this is rustc bug, which can be worked around by disabling optimizations. "working on c++ optimizers" could only make matters worse for buggy code

First, the LLVM developers agree that it's an LLVM bug and it also causes Clang to miscompile things in violation of the C11 standard.

Second, I'm guessing you didn't read the issue threads I linked. There's no simple toggle for just the problematic behaviour within LLVM.

For example, here are a few comments from the issue on the Rust tracker:

Is the loop removal an optimization pass that we could simply remove?

It's unfortunately not just a loop-deletion pass. The problem arises from broad assumptions, for example: (a) branches have no side effects, (b) functions that contain no instructions with side effects have no side effects, and (c) calls to functions with no side effects can be moved or deleted.

To be fair to LLVM, compiler writers don't approach this topic from the perspective of "I'm going to write an optimization that proves loops are non-terminating, so that I can pedantically optimize them away!" Instead, the assumption that loops will either terminate or have side effects just arises naturally in some common compiler algorithms.