------- Comment #4 from hutchinsonandy at aim dot com 2008-03-09 18:36 -------
The problem is not commutation knowledge to the backend.
First - the use notes were a red herring. Reversing them did not help.
After much chasing thru call.c and optabs.c, it looks like neither creates nor
correct the issue.
But I can fix (hide) the issue by commutating the back end expander to get
optimal code. (Of course that does not fix ALL binop libcalls!)
So I tried a non-commutative operator (% or /) - and that was optimal, with no
expander changes.
So it would appear that the default "don't care" order presented to
expand_binop() is wrong. Where it does critically matter (non-commutative
functions), the order is ideal.
The effect on chained arithmetic or higher modes such as DImode is horrendous,
and may explain other noted problems with optimizations.
FYI here is expander used to temporarily fix (hide) problem - NOTE operand
numbering, relative to RTL order.
(define_expand "mulsi3"
[(set (reg:SI 18) (match_operand:SI 1 "register_operand" "r"))
(set (reg:SI 22) (match_operand:SI 2 "register_operand" "r"))
(parallel [(set (reg:SI 22) (mult:SI (reg:SI 22) (reg:SI 18)))
(clobber (reg:HI 26))
(clobber (reg:HI 30))])
(set (match_operand:SI 0 "register_operand" "=&r") (reg:SI 22))]
"AVR_HAVE_MUL"
"")
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
