Hi All,
I just wanted to thank you for your help; I was able to fix the problem with
the following RTL
(define_expand "addhi3"
[(set (match_operand:HI 0 "nonimmediate_operand")
(plus:HI (match_operand:HI 1 "nonimmediate_operand")
(match_operand:HI 2 "general_operand")))]
""
{
if((GET_CODE(operands[2]) == CONST_INT) &&
((INTVAL(operands[2]) > 4095) || (INTVAL(operands[2]) < -2048)))
{
emit_insn(gen_addhi3_mem_or_reg(operands[0], operands[1],
force_reg(HImode, operands[2])));
DONE;
}
})
;;*****************************************************************************
;;** This pattern is for any register or memory target. This pattern cannot**
;;** accept immediate values over 12 bits hence the expand above. **
;;*****************************************************************************
(define_insn "addhi3_mem_or_reg"
[(set (match_operand:HI 0 "nonimmediate_operand" "=a,m")
(plus:HI (match_operand:HI 1 "nonimmediate_operand" "%0,0")
(match_operand:HI 2 "general_operand" "aim,aim")))]
""
{
output_asm_insn("//Start of addhi3_mem_or_reg %0 = %1 + %2", operands);
snap_do_basic_math_op_hi(operands, MATH_OP_PLUS);
output_asm_insn("//End of addhi3_mem_or_reg", operands);
return("");
}
)
Nathan and Johann if you are even in Fort Collins, CO I will buy you a beer. :)
Steve
On Wednesday, January 18, 2017 8:47 AM, Georg-Johann Lay <a...@gjlay.de> wrote:
On 17.01.2017 21:41, Steve Silva via gcc wrote:
> Hi Nathan,
>
> Thanks for your advice. I retooled the addhi3 sequence to look like this:
>
> (define_expand "addhi3"
> [(set (match_operand:HI 0 "snap_mem_or_reg" "+a,m")
> (plus:HI (match_operand:HI 1 "snap_mem_or_reg" "%0,0")
> (match_operand:HI 2 "general_operand" "aim,aim")))]
Expanders don't take constraints; you should get a warning here.
> ""
> ""
> )
You can omit trailing elements if they are empty:
(define_expand "addhi3"
[(set (match_operand:HI 0 "snap_mem_or_reg")
(plus:HI (match_operand:HI 1 "snap_mem_or_reg")
(match_operand:HI 2 "general_operand")))])
If you are allowing MEM here the generated insn might come
with a memory operand. Disallowing it in the insn predicate
might lead to "unrecognizable insn" ICE, e.g. if op 1 is
a MEM and op 0 is a REG.
> (define_insn "addhi3_regtarget"
> [(set (match_operand:HI 0 "register_operand" "+a")
operands[0] is not an input here, it's only an output.
Hence "=a" is the right constraint, not "+a".
> (plus:HI (match_operand:HI 1 "register_operand" "%0")
> (match_operand:HI 2 "general_operand" "aim")))]
> ""
> {
> output_asm_insn("//Start of addhi3_regtarget %0 = %1 + %2", operands);
> snap_do_basic_math_op_hi(operands, MATH_OP_PLUS);
> output_asm_insn("//End of addhi3_regtarget", operands);
> return("");
> }
> )
>
>
> (define_insn "addhi3_memtarget"
> [(set (match_operand:HI 0 "memory_operand" "+m")
> (plus:HI (match_operand:HI 1 "memory_operand" "%0")
> (match_operand:HI 2 "general_operand" "aim")))]
You might consider one insn with several alternatives like:
(define_insn "*addhi3_insn"
[(set (match_operand:HI 0 "nonimmediate_operand" "=a ,m")
(plus:HI (match_operand:HI 1 "register_operand" "%0 ,0")
(match_operand:HI 2 "general_operand" "aim,aim")))]
""
{
// Output depending on which_alternative.
return "";
})
Johann
> ""
> {
> output_asm_insn("//Start of addhi3_memtarget %0 = %1 + %2", operands);
> snap_do_basic_math_op_hi(operands, MATH_OP_PLUS);
> output_asm_insn("//End of addhi3_memtarget", operands);
> return("");
> }
> )
>
> I compile a simple program with this:
>
> void addit()
> {
> int a, b, c;
>
> a = -10;
> b = 2;
> c = a + b;
> }
>
>
> And the compiler fails out with the following message:
>
> addit.c: In function 'addit':
> addit.c:12:1: internal compiler error: in find_reloads, at reload.c:4085
> }
> ^
> 0x8f5953 find_reloads(rtx_insn*, int, int, int, short*)
> ../../gcc-6.2.0/gcc/reload.c:4085
> 0x90327b calculate_needs_all_insns
> ../../gcc-6.2.0/gcc/reload1.c:1484
> 0x90327b reload(rtx_insn*, int)
> ../../gcc-6.2.0/gcc/reload1.c:995
> 0x7e8f11 do_reload
> ../../gcc-6.2.0/gcc/ira.c:5437
> 0x7e8f11 execute
> ../../gcc-6.2.0/gcc/ira.c:5609
>
> It would seem that the constraints are somehow not right, but I am not
> familiar with the particular way the compiler does this step. Any insights
> or pointers?
>
>
> Thanks,
>
> Steve S
[snipped TOFU]
