I must be missing something here, but can't you simply not invoke undefined behavior in your program? That way, you don't have to worry about what your compiler will do when it encounters undefined behavior.
The Problem with Friendly C
91–100 of 174 posts
Re: The Problem with Friendly C
#92Earlier quoted context omitted.
I agree optimization is important. So important that it should be pushed down into the hardware. Binaries should look almost like source code. But that's just my vision for what it's worth.
Hardware already does insane amounts of optimization. The modern superscalar out of order processor basically does it's own JIT from X86 into their own internal micro-ops. Reordering instructions on the go etc. That's another 2-10x speed difference on modern computers.
Completely agree :) But even better to push C code straight down to the hardware and let it crunch on that! Let it allocate a few thousand registers, or spawn off an FPGA compiler to create a few new instructions. Crazy?
Re: The Problem with Friendly C
#93Being an ignorant fool with an uninformed opinion, I would like to see a C compiler that is evaluated and critiqued not only based on the warnings and errors it generates but, more importantly, on the assembly it generates. Namely, how compact and readable is the generated asm? When we read the asm, can we easily follow what the compiler has done and _why_? As an ignorant fool, in my mind C is still a shorthand for w…
I agree it would be an interesting exercise to write a compiler optimized for assembly readability. But I don't think there is enough demand for such a thing so that it will get written. It also would be interesting if those who think there is enough demand start a crowdfunding campaign to prove that there is enough demand.
> But I don't think there is enough demand for such a thing so that it will get written.
Isn't that basically what we have academia for?
Re: The Problem with Friendly C
#94Being an ignorant fool with an uninformed opinion, I would like to see a C compiler that is evaluated and critiqued not only based on the warnings and errors it generates but, more importantly, on the assembly it generates. Namely, how compact and readable is the generated asm? When we read the asm, can we easily follow what the compiler has done and _why_? As an ignorant fool, in my mind C is still a shorthand for w…
Most C compilers have a flag to turn this mode on. It's usually called -O0 and is actually the default.
Re: The Problem with Friendly C
#95Fun fact about large shifts being undefined. With a 32 bit x, the expression x > (32 - b) can be translated to a single "roll x b bits to the left" instruction. But it is only possible if >32 shifts are treated as undefined.
Not true. In fact, modern x86 backends recognize the safe rotation idiom and also translate it to a single ROL instruction: http://goo.gl/NCMEVu http://goo.gl/9Ytsz2 http://goo.gl/vbzHNW
Re: The Problem with Friendly C
#96Re: The Problem with Friendly C
#97Being an ignorant fool with an uninformed opinion, I would like to see a C compiler that is evaluated and critiqued not only based on the warnings and errors it generates but, more importantly, on the assembly it generates. Namely, how compact and readable is the generated asm? When we read the asm, can we easily follow what the compiler has done and _why_? As an ignorant fool, in my mind C is still a shorthand for w…
C doesn't turn into some magical obtuse assembly with optimizations enabled, a loop will still be visible in some way but might vectorized, unrolled, eliminated or even merged but you can still map it to the source. It's interesting to see what a compiler can do: ICC does some really fancy stuff such as eliminating whole chunks of code that are meant to help most compilers vectorize.
Re: The Problem with Friendly C
#98Tone: I do not mean this as sarcasm or merely chasing fashion, I'm quite serious. As both theory and practice are showing, you're never going to be able to get the consensus you want out of C. There's no "saving" C... not because that's somehow mathematically impossible, but simply because the project is too staggeringly large for us to even wrap our heads around. It would literally be easier to get people to start u…
I love the ideas behind Rust. I don't think it can replace C for all use-cases.
C has the use-case of zero-dynamic-allocations. AFAIK, Rust is not very compatible with that mode of use.
Re: The Problem with Friendly C
#99Earlier quoted context omitted.
> On strict aliasing, I'm against it without explicit opt-in over a delimited subset of source code. I understand that using & is going to harm the performance of my code; I think that's an acceptable tradeoff for more predictable behaviour. I believe that you and others think that's an acceptable tradeoff. At the end of the day, though, most people want C compilers to produce the fastest code possible. Compiler auth…
I'm not sure that's the best example. In that case, the knowledge that the 'array' global never has its address taken allows you to perform the optimization. You can also rewrite it by copying 'array' to a separate local that doesn't have its address taken, and ordinary SSA construction solves the problem. I feel like a new systems language needs to come and make aliasing explicit in a way, so that it doesn't surpris…
> I'm not sure that's the best example. In that case, the knowledge that the 'array' global never has its address taken allows you to perform the optimization.
Separate translation units. For this to work, you'd need to postpone all optimizations to the link stage. Even then you're not safe, because you may be producing a dynamic library and the program loading it can take the address of an object by dlsym().
Re: The Problem with Friendly C
#100Earlier quoted context omitted.
IMHO aggressive optimization at compile time is an example of premature optimization. Let the hardware have access to a straightforward representation. Once the run-time hot-spots are identified, the hardware (firmware, VM, whatever) can rewrite the binary code to execute faster. Excessive compiler optimization makes this difficult or impossible (too much information thrown away.) Compilers should be designed for fas…
It doesn't really seem like this solves the problem of optimizers introducing bugs and vulnerabilities. Take the canonical optimizer-created security hole: the hardware optimizer replaces a constant-time compare (which doesn't leak timing information) with a variable-time compare (which does). I don't think this solves the problem we're setting out to solve, ie. the optimizer introducing bugs.
That good point, replacing a constant time compare with a non constant time compare is a very terrible bug to introduce.
A more amusing issue I saw was an optimization that looked for places where it could replace manual memory copying with ca call to memcpy. Something that drove the guys writing libc nutzoid. Because it was replacing the code in memcpy with a call to memcpy. (On some platforms you can implement memcpy with special assembly language calls. On some you can't)
Personally I care little about speed, since if I need more speed I can get that. And frankly if you tell me the resulting binary is 20% faster for some things, I just do not care. But I worry a lot about losing the ability to reason about side effects.