Comments by "LoneTech" (@0LoneTech) on "Creel" channel.

@bpark10001 Compilers are rarely perfect. They are, however, tested by a wide variety of programmers, and generally written and debugged by large numbers of highly experienced programmers over considerable time. If your compiler needs adjustment to prevent crashes, you're either instructing it to target a machine quite different from the one you use, or you're using an exceptionally bad compiler. Far more likely it is your computer that is unreliable and exposes unpredictable behaviour under load, such as heavy optimization passes. Because nearly all software is compiled, the compiler itself is simply the most thoroughly tested program.
24
@Henrik_Holst No, branches are distinct from conditionals. In this case, we see it transferring a condition flag into a general purpose register value using SETc instructions, because x86 has a condition flag register; not all architectures do. Conditional instructions like x86 CMOV or AVR SBRS operate by cancelling the retire step of a single instruction, which doesn't divert the instruction decoding; that's a cheaper form of branching. What you say would apply to architectures where the condition test is embedded only within branch instructions, as if you removed the CMP* instructions and had to use B* instructions in Nios II. That would be a typical case where a compiler might have a different optimization to avoid the issue, like using the sign bit from a subtraction.
20
If you find the compiler doing something dumb, it's often better to make a small tweak to clarify what the compiler didn't get rather than do all of its work. Case in point, with the ToUpperCPP at 8:47, GCC -O3 will produce an SSE version if you tweak "if (cond) d[i] -= 32;" to "d[i] -= cond ? 32 : 0;"
7
@adytya Either reason it out, or measure. Preferably measure either way, actually, so you can tell if you're making progress. The task of measuring program performance is called profiling, so look for profiling tools, e.g. gprof.
3
@ALivingDinosaur GCC generates 32 bytes per iteration if you tell it the processor will support it, with e.g. -march=native or -mavx2.
2
@pikachulovesketchup666 I believe I wrote my comment in the context of the compiler itself crashing. You're right that varying optimization can expose different program behaviours when the behaviour is undefined in the first place. Sadly often that type of bug relates to CPU bugs the compiler doesn't know to work around.
1
The trick is to not make your code that much harder to read. "p[i] -= p[i]>='a' && p[i]<='z' ? 'a'-'A' : 0;" is a whole lot easier to read than the multiply mess. It tells the compiler that it should update p[i] regardless, but in some cases the difference is 0. It also gives a hint to a reading human that the value has to do with the letter case. Maps and guards could make it easier to understand still.
1