That this series has been published so close to WWDC makes me wonder if we're being prepared for some announcement.
Edit: although it's more likely that Lattner is just bracing himself for the onslaught of questions he'll have to field and hoping to be able to refer people to these articles.
I've vaguely looked at each of these, being a c++ programmer rather a "true" c programmer.
One thing that was a little annoying was their discussion about purpose of undefined behavior. That is, I don't believe "undefined behavior" in the C Language exists for speed as such. Rather, undefined behavior is machine-specific behavior and it exists in C so the programmer can write machine specific code, the C Language being a "high-level assembly language" or "system-programmer's Swiss army knife". Speed is one outcome, certainly but there are other ways to get speed (a Just In Time Compile can come at least close naive c code). The point isn't speed. The point is "do anything", the point is that a chip designer can write c code and look on his screen to see the resulting assembler and decide where to go from there.
It may be the llvm folks bypass this point because llvm is "virtual machine" rather than a chip. But it is slight annoying not to mention this if "What Every C Programmer Should Know"
Perhaps they should have called their article "what C-programmers should know about optimizing compilers..."
> One thing that was a little annoying was their discussion about purpose of undefined behavior. That is, I don't believe "undefined behavior" in the C Language exists for speed as such. Rather, undefined behavior is machine-specific behavior and it exists in C so the programmer can write machine specific code, the C Language being a "high-level assembly language" or "system-programmer's Swiss army knife". Speed is one outcome, certainly but there are other ways to get speed (a Just In Time Compile can come at least close naive c code). The point isn't speed. The point is "do anything", the point is that a chip designer can write c code and look on his screen to see the resulting assembler and decide where to go from there.
If this were really the case, then they would have made the behavior implementation-defined rather than undefined.
A lot of the choices of undefined behavior seem like they were made due to the laziness of implementors, especially the purely syntactic ones, e.g. token pasting creating multiple tokens or unmatched quotes. It is pretty crazy that a C compiler is allowed to do anything if you miss a closing quotation.
One thing that was a little annoying was their discussion about purpose of undefined behavior.
Could you quote an offending passage that claims that the purpose of undefined behavior is for speed? I see discussion of how undefined behavior creates opportunities for optimization, but nothing about purpose. Indeed, the word "purpose" does not appear in parts 1, 2, or 3 at all.
So please share whatever passage has the semantics you claim.
It may be the llvm folks bypass this point because llvm is "virtual machine" rather than a chip.
I'm curious: what exactly do you mean by this?
I don't mean to be rude, but whenever I read anybody say that LLVM is a virtual machine, it always comes off as if everything they know about LLVM came from learning the acronym.
Pohl: Could you quote an offending passage that claims that the purpose of undefined behavior is for speed?
Me: How a-bout, "Undefined behavior exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language."*??
I see, it's a historical claim without a citation. What kind of machine was it back then, a PDP-11? I suppose it's possible they would want to save cycles here & there. Do you know something specific about the history here?
I do not believe that claim. As an example: register allocation is a form of optimization. Do you have a compiler that honors all 'register' declarations, puts nothing else in registers, and bails out if it runs out of registers?
Also, are you sure your compiler always executes all espressions in the order they appear in your source code? Are you laying out _all_ your memory structures by hand, or are you counting on your compiler to do the beet it can do for most of them?
If you have, say, #define WIDTH 1024 #define HEIGHT 768, does your compiler compile a multiplication instruction for "long x = WIDTH * HEIGHT;"?
I think the only way to program C without using any form of optimization is by having one big asm block and nothing else.
What compiler and compiler flags are you using on what architecture?
Edit: although it's more likely that Lattner is just bracing himself for the onslaught of questions he'll have to field and hoping to be able to refer people to these articles.