Strange insn rtx is emitted in a custom backend

[Jeff Law]

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