On 2015.11.07 at 02:09 +0100, Vincent Lefevre wrote: > On 2015-11-05 22:23:01 +0100, Markus Trippelsdorf wrote: > > On 2015.11.05 at 21:52 +0100, David Brown wrote: > > > There has been some discussions going on in the comp.lang.c newsgroup > > > about how far compilers are allowed to go regarding optimisation using > > > their knowledge of undefined behaviour (i.e., if a piece of code has > > > undefined behaviour, the compiler can assume that the user does not care > > > about the result in that case, and can therefore do whatever it wants in > > > order to generate faster code). > > > > The compiler just assumes that undefined behavior will not happen and > > optimizes accordingly. > > That's undefined by the C standard and this is useful for some > optimizations, but it would be great if GCC could, as an extension, > provide builtins with some well-defined behavior in cases that would > be UB by the C standard. > > Let me give an example. I have a code that must run as fast as possible. > There is a 64-bit integer division. A division by 0 is possible, but > occurs with a very low probability (something like 1/2^64, I assume). > When it occurs, anything that would yield an abnormal termination is > acceptable (no other behavior is acceptable). I could do a test, but > this would slow down the code, while the x86 division instruction > generates a trap in case of division by 0, so that such an instruction > could be used alone (with no associated test). So, such a builtin would > be very useful. You could annotate the test with __builtin_expect() and see if it helps. -- Markus
