This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
It's also worth noting that some ports have hacks to encourage 4->1 or 4->2 combinations. Basically they have patterns which represent an intermediate step in a 4->1 or 4->2 combination even if there is no machine instruction which implements the insn appearing in the intermediate step. I've used (and recommended) this trick numerous times through the years, so I suspect these patterns probably exist in many ports.What does the code look like, that is optimized so much better with 4 insns to combine? It looks like code that could come from bitfield manipulations, which is an area where it's well-known that GCC does not always optimize too well.Here are some typical examples. Some of it is bitfield operations. PR42172 is. Also, from gimplify.s:
(define_insn "" [(set (match_operand:SI 0 "register_operand" "=a") (plus:SI (mult:SI (sign_extend:SI (mem:HI (post_inc:SI (match_operand:SI 1 "register_operand" "r")))) (sign_extend:SI (mem:HI (post_inc:SI (match_operand:SI 2 "register_operand" "r"))))) (match_operand:SI 3 "register_operand" "0")))] "TARGET_MAC" "mac @%2+,@%1+" [(set_attr "length" "4") (set_attr "cc" "none_0hit")])
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |