>> Even then you assume the profile resembles the real program input. Not always true. >That is at least somewhat relevant, but your original comment stated th

>> Even then you assume the profile resembles the real program input. Not always true. >That is at least somewhat relevant, but your original comment stated that GCC can not make usage-based optimisations, not that it won't always make the right ones. There are things that PGO can not optimize away that an optimistic JIT+managed runtime can. > GCC can do one better, given dereferencing null pointers is illegal it doesn't need to handle that at all, and thus has no need to optimise something which doesn't exist. Unfortunately, null pointer deference do exist even if their behavior is "implementation specific" in C, segfaults are depressingly common. And if you take CCJ as an AOT compiler then GCC as compiler collection can not make that optimization. I think this points to a philosophical in difference between JVM compilers and GCC+ICC compilers. The JVM optimizes things away because behavior is defined in a certain way, while GCC tends to say you are asking for undefined behavior so I don't bother to do what you asked at all. So I would not call it do one "better, it really is do one "worse"