Le primidi 11 brumaire, an CCXXVI, Clement Boesch a écrit : > My bad, you're right, I was looking at the wrong header with the same > variable names. Dismiss my comment.
Ok, series pushed. > I'd say that a counter is unlikely to require a sign vs unsigned > optimization (and if it does and we know the counter is positive only, we > can explicit it with bit shifts etc). OTOH, the compiler will always have > to assume an overflow can happen if the initial counter value comes from > another variable, and you can't do much to hint it about it. Assuming a > loop overflow has IMO much more impact of what the compiler can do in the > general logic of the loop. But that's pure speculation from me. I find the conclusion that lying to the compiler would help it make the code faster it hard to swallow. I think the real logic is this: unsigned, since they have a much simpler semantic, have been optimized efficiently by compilers for a long time. Recently, compilers have learned to use undefined behaviours to optimize signed further, almost as much as unsigned. But not better. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
