Summary: | unsigned char times 64U produces long slow loop | ||
---|---|---|---|
Product: | gcc | Reporter: | Michael Hennebry <hennebry> |
Component: | target | Assignee: | aesok |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aesok, eric.weddington, gcc-bugs, gjl |
Priority: | P3 | Keywords: | missed-optimization |
Version: | 4.3.2 | ||
Target Milestone: | 4.7.0 | ||
Host: | Target: | avr-*-* | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2009-02-19 18:37:06 |
Description
Michael Hennebry
2009-02-19 17:51:18 UTC
Hi. The GCC always use a shift for optimizing multiply by power of 2 constant. expr.c:expand_expr_real_1:8680 .... /* Check for a multiplication with matching signedness. */ else if (TREE_CODE (TREE_OPERAND (exp, 0)) == NOP_EXPR && TREE_CODE (type) == INTEGER_TYPE && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (exp, 0), 0))) < TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (exp, 0)))) && ((TREE_CODE (TREE_OPERAND (exp, 1)) == INTEGER_CST && int_fits_type_p (TREE_OPERAND (exp, 1), TREE_TYPE (TREE_OPERAND (TREE_OPERAND (exp, 0), 0))) /* Don't use a widening multiply if a shift will do. */ && ((GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (TREE_OPERAND (exp, 1)))) > HOST_BITS_PER_WIDE_INT) || exact_log2 (TREE_INT_CST_LOW (TREE_OPERAND (exp, 1))) < 0)) expmed.c:expand_mult ... if (coeff != 0) { /* Special case powers of two. */ if (EXACT_POWER_OF_2_OR_ZERO_P (coeff)) return expand_shift (LSHIFT_EXPR, mode, op0, build_int_cst (NULL_TREE, floor_log2 (coeff)), target, unsignedp); For the AVR target for multiply by 2 with using a shift give better code, but for multiply by 4,8, ... using a shift is bad and for code size and for speed. I think this optimization should not be hard coded, but should be chosen based on the insn cost data. Perhaps there are other targets, which is better to use multiplication rather than a shift. Anatoly. This is solved in 4.7 *** This bug has been marked as a duplicate of bug 49687 *** (In reply to comment #2) > This is solved in 4.7 > > *** This bug has been marked as a duplicate of bug 49687 *** 49687 is still unassigned. Did you mean to be solved in 4.7? (In reply to comment #3) > (In reply to comment #2) > > This is solved in 4.7 > > > > *** This bug has been marked as a duplicate of bug 49687 *** > > 49687 is still unassigned. > Did you mean to be solved in 4.7? Oops. I should learn to scroll. |