On 02/22/2017 02:40 PM, Jakub Jelinek wrote:
Hi!If both arguments of integer division or modulo are known to be non-negative in corresponding signed type, then signed as well as unsigned division/modulo shall have the exact same result and therefore we can choose between those two depending on which one is faster (or shorter for -Os), which varries a lot depending on target and especially for constant divisors on the exact divisor. expand_divmod itself is too complicated and we don't even have the ability to ask about costs e.g. for highpart multiplication without actually expanding it, so this patch just in that case tries both sequences, computes their costs and uses the cheaper (and for equal cost honors the actual original signedness of the operation). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-02-22 Jakub Jelinek <ja...@redhat.com> PR middle-end/79665 * internal-fn.c (get_range_pos_neg): Moved to ... * tree.c (get_range_pos_neg): ... here. No longer static. * tree.h (get_range_pos_neg): New prototype. * expr.c (expand_expr_real_2) <case TRUNC_DIV_EXPR>: If both arguments are known to be in between 0 and signed maximum inclusive, try to expand both unsigned and signed divmod and use the cheaper one from those.
OK. jeff
