https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to H. Peter Anvin from comment #14) > A bigger, philosophical question: we are always told that builtins are > better for the compiler than inline assembly, as it gives the compiler more > information both for scheduling and behavioral purposes. Does that not apply > to this situation? If so, why not? Different philosophical. Is introducing builtins that have huge undefined behaviors (a trap) is wrose than having inline-asm? The answer is yes it is. Plus division will almost never be useful for scheduling purposes anyways. As far as Behavioral purposes, you introduce a builtin which has very dynamic undefined behavior one which you need to do a full division to figure out at runtime so the savings for using the builtin is just lost when compiling with -fsanitize=undefined anyways. The division has no big savings unless you 100% know the lower bits are going to be 0 for the result always. Which in many cases you don't. Adding the builtin is also years away from then supporting it in other software. So you still need a fall back to the inline-asm for most code for at least the next 5-10 years anyways :).
