Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every compiler writer should know about programmers (2015) [pdf]

complang.tuwien.ac.at

Post reply on HN
Print view View original

21–30 of 101 posts

Re: What every compiler writer should know about programmers (2015) [pdf]

#21

Post by HexDecOctBin »

Joker_vD wrote: post #5

In the end it all boils to a very simple argument. The C programmers want the C compilers to behave one way, the C implementers want the C compilers to behave the other way. Since the power structure is what it is — the C implementers are the ones who write the C standard and are the ones who actually get to implement the C compilers — the C compilers do, and will, behave the way the C implementers want them to. In t…

Another alternative is that the programmer write their own C compiler and be free of this politics. Maybe I am biased since I am working on exactly such a project, but I have been seeing more and more in-progress compiler implementations for C or C-like languages for the past couple years.

Re: What every compiler writer should know about programmers (2015) [pdf]

#22

Post by deathanatos »

catlifeonmars wrote: post #15
BeeOnRope wrote: post #14

Earlier quoted context omitted.

Dead code is extremely common in C or C++ after inlining, other optimizations.

OP means that the code has a dual purpose: one purpose is to be compiled, the other is to communicate structure or intent to programmers.

Do we know that? I've written "dead" code. It's point was to communicate structure or intent, but it was also still dead. This pattern, in one form or another, crops up a lot IME (in multiple languages, even, with varying abilities to optimize it):

  if condition that is "always" false:
    abort with message detailing the circumstances
That `if` is "dead", in the sense that the condition is always false. But "dead" sometimes is just a proof — or if I'm not rigourous enough, an assumption — in my head. If the compiler can prove the same proof I have in my head, then the dead code is eliminated. If can't, well, presumably it is left in the binary, either to never be executed, or to be executed in the case that the proof in my head is wrong.

Re: What every compiler writer should know about programmers (2015) [pdf]

#23

Post by BeeOnRope »

somat wrote: post #20
BeeOnRope wrote: post #14

Earlier quoted context omitted.

Dead code is extremely common in C or C++ after inlining, other optimizations.

That's the problem

Why is that a problem? Inlining and optimization aren't minor aspects of compiling to native code, they are responsible for order-of-magnitude speedups.

My point is that it is easy to say "don't remove my code" while looking at a simple single-function example, but in actual compilation huge portions of a function are "dead" after inlining, constant propagation and other optimizations: not talking anything about C-specific UB or other shenanigans. You don't want to throw that out.

Re: What every compiler writer should know about programmers (2015) [pdf]

#24

Post by twoodfin »

chc4 wrote: post #10
Joker_vD wrote: post #4

Earlier quoted context omitted.

Wow, that's a very torturous reading of a specific line in a standard. And it doesn't really matter what Yodaiken thinks this line means because standard is written by C implementers for (mostly) C implementers. So if C compile writers think this line means they can use UB for optimizing purposes, then that's what it means. Yeah, I know it breaks the common illusion among the C programmers that they're "close to the…

Yeah, this is basically Sovereign Citizen-tier argumentation: through some magic of definitions and historical readings and arguing about commas, I prove that actually everyone is incorrect. That's not how programming languages work! If everyone for 10+ years has been developing compilers with some definition of undefined behavior, and all modern compilers use undefined behavior in order to drive optimization passes…

Aliasing being the classic example. If code generation for every pointer dereference has to assume that it’s potentially aliasing any other value in scope, things get slow in a hurry.

Re: What every compiler writer should know about programmers (2015) [pdf]

#25

Post by somat »

chc4 wrote: post #10
Joker_vD wrote: post #4

Earlier quoted context omitted.

Wow, that's a very torturous reading of a specific line in a standard. And it doesn't really matter what Yodaiken thinks this line means because standard is written by C implementers for (mostly) C implementers. So if C compile writers think this line means they can use UB for optimizing purposes, then that's what it means. Yeah, I know it breaks the common illusion among the C programmers that they're "close to the…

Yeah, this is basically Sovereign Citizen-tier argumentation: through some magic of definitions and historical readings and arguing about commas, I prove that actually everyone is incorrect. That's not how programming languages work! If everyone for 10+ years has been developing compilers with some definition of undefined behavior, and all modern compilers use undefined behavior in order to drive optimization passes…

I find where the argument gets lost is when undefined behavior is assumed to be exactly that, an invariant.

That is to say, I find "could not happen" the most bizarre reading to make when optimizing around undefined behavior "whatever the machine does" makes sense, as does "we don't know". But "could not happen???" if it could not happen the spec would have said "could not happen" instead the spec does not know what will happen and so punts on the outcome, knowing full well that it will happen all the time.

The problem is that there is no optimization to make around "whatever the hardware does" or "we have no clue" so the incentive is to choose the worst possible reading "undefined behavior is incorrect code and therefore a correct program will never have it".

Re: What every compiler writer should know about programmers (2015) [pdf]

#26

Post by groestl »

WalterBright wrote: post #8
Joker_vD wrote: post #5

In the end it all boils to a very simple argument. The C programmers want the C compilers to behave one way, the C implementers want the C compilers to behave the other way. Since the power structure is what it is — the C implementers are the ones who write the C standard and are the ones who actually get to implement the C compilers — the C compilers do, and will, behave the way the C implementers want them to. In t…

> behave the way the C implementers want them to If you don't please your users, you won't have any users.

If you're self hosting your compiler on C, you are your own user.

Re: What every compiler writer should know about programmers (2015) [pdf]

#27

Post by nananana9 »

Compiler developers hijacked and twisted the term "Undefined Behavior". Everyone understood what UB was in K&R C - if you write code that the standard doesn't define a meaning to, and the compiler outputs what it outputs. If you dereference a null pointer, the compiler outputs a null pointer dereference, and when you hit it at runtime you get the undefined behavior (page fault on modern systems).

Nowadays, UB means something completely different - if at any point in time, the compiler reasons out that a piece of code is only reachable via UB, it will assume that this can never happen, and will quietly delete everything downstream:

https://godbolt.org/z/EYxWqcfjx

Re: What every compiler writer should know about programmers (2015) [pdf]

#28

Post by godelski »

WalterBright wrote: post #8
Joker_vD wrote: post #5

In the end it all boils to a very simple argument. The C programmers want the C compilers to behave one way, the C implementers want the C compilers to behave the other way. Since the power structure is what it is — the C implementers are the ones who write the C standard and are the ones who actually get to implement the C compilers — the C compilers do, and will, behave the way the C implementers want them to. In t…

> behave the way the C implementers want them to If you don't please your users, you won't have any users.

Which users?

Re: What every compiler writer should know about programmers (2015) [pdf]

#29

Post by stinkbeetle »

rurban wrote: post #12

This was 2015, and we still have no -Wdeadcode, warning of removal of "dead code", ie what compilers think of dead code. If a program writer writes code, it is never dead. It is written. It had purpose. If the compiler thinks this is wrong, it needs to warn about it. The only dead code is generated code by macros.

That's not true for all code bases. Two common examples:

It's very common for inline functions in headers to be written for inlining and constant propagation from arguments result in dead code and better generated code. There is even __builtin_constant_p() to help with such things (e.g., you can use it to have a fast folded inline variant if an argument is constant, or call big out of line library code if variable).

There are also configuration systems that end up with config options in headers that code tests with if (CONFIG_BLAH) {...} that can evaluate to zero in valid builds.

Re: What every compiler writer should know about programmers (2015) [pdf]

#30

Post by fluoridation »

somat wrote: post #25
chc4 wrote: post #10

Earlier quoted context omitted.

Yeah, this is basically Sovereign Citizen-tier argumentation: through some magic of definitions and historical readings and arguing about commas, I prove that actually everyone is incorrect. That's not how programming languages work! If everyone for 10+ years has been developing compilers with some definition of undefined behavior, and all modern compilers use undefined behavior in order to drive optimization passes…

I find where the argument gets lost is when undefined behavior is assumed to be exactly that, an invariant. That is to say, I find "could not happen" the most bizarre reading to make when optimizing around undefined behavior "whatever the machine does" makes sense, as does "we don't know". But "could not happen???" if it could not happen the spec would have said "could not happen" instead the spec does not know what…

Some behaviors are left unspecified instead of undefined, which allows each implementation to choose whatever behavior is convenient, such as, as you put it, whatever the hardware does. IIRC this is the case in C for modulo with both negative operands.

I would imagine that the standard writers choose one or the other depending on whether the behavior is useful for optimizations. There's also the matter that if a behavior is currently undefined, it's easy to later on make it unspecified or specified, while if a behavior is unspecified it's more difficult to make it undefined, because you don't know how much code is depending on that behavior.

Post reply on HN