Thanks a lot, Jeff! I was missing some stuff in TARGET_LEGITIMATE_CONSTANT_P.
Lev. On Mon, Jun 1, 2015 at 11:35 PM, Jeff Law <l...@redhat.com> wrote: > On 06/01/2015 12:51 PM, Lev Yudalevich wrote: >> >> While working on a custom backend for quite a standard RISC-like >> architecture, I defined 'high'/'lo_sum' patterns as follows: >> >> (define_insn "mov_high" >> [(set (match_operand:SI 0 "register_operand" "=r") >> (high:SI (match_operand:SI 1 "immediate_operand" "i")))] >> "" >> "mvup #high(%1), %0" >> [(set_attr "insn" "alu") >> (set_attr "length" "4")] >> ) >> >> (define_insn "add_low" >> [(set (match_operand:SI 0 "register_operand" "=r") >> (lo_sum:SI (match_operand:SI 1 "register_operand" "0") >> (match_operand:SI 2 "symbolic_operand" "")))] >> (match_operand:SI 2 "immediate_operand" >> "i")))] >> "" >> "add3 %0, #low(%2), %0" >> [(set_attr "insn" "alu") >> (set_attr "length" "4")] >> ) >> >> >> Despite having the patters above (along with usual 'plus' patterns) >> I'm getting the following rtx emitted at the expansion stage: >> >> (insn 53 52 63 2 (set (reg:SI 62) >> (const:SI (plus:SI (symbol_ref:SI [flags >> 0x6]) >> (const_int >> 64 [0x40])))) -1 >> (nil)) >> >> which can not be recognized unless I define a pattern like this: > > You should debug precisely where that came from. You're missing something > in your backend to tell GCC that such constants are not valid. > > You should probably look at how expansion occurs for your tests on other > ports that make heavy use of high/lo_sum. sparc & hppa come immediately to > mind, but I'm sure there's others. > > jeff >
