On 04/26/2011 04:51 AM, Georg-Johann Lay wrote: > As the SFRs are volatile, insv expander skips > them and a combine pattern must care of them. Omitting the complicated > bit-plethora patterns I still see long, slow shift loops for HI. So > the patch still includes them.
Why don't we focus on doing the right thing for plain registers first, and worry about volatile SFRs second? In particular, combine *should* be doing the right thing for registers, putting those AND/OR/SHIFT whatsits back into insv/extv form, via make_compound_operation. > The snip "INTVAL(operands[...])" occurs more than 50 times in the > machine description. Wouln't it be good to have an abbreviation like > #define OPVAL(n) INTVAL(operands[n])) defined in, e.g. avr-protos.h? No, what would be better is to define more predicates. Though in the case of comparing op2 vs op4, there's probably no helping it. >> +(define_insn "*movbitqi_ext_reg" >> + [(set (zero_extract:QI >> + (match_operand:QI 0 "register_operand" "+*d,*d,r,r,r") >> + (const_int 1) >> + (match_operand 1 "const_0_to_7_operand" "")) >> + (match_operand:QI 2 "nonme > > Why do you use "*d" as constraint and not "d"? Premature optimization. But what it means is ignore "d" as a register allocation class and only consider "r". Why are you adding "optimize" to all these insns? None of them will be matched unless combine is run, which implies optimization. r~
