Strange insn rtx is emitted in a custom backend

[Lev Yudalevich]

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 <law@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
>