> On Tue, May 12, 2015 at 10:17:01PM +0000, James Bowman wrote: > > It seems that with whenever a function's frame is bigger than 512 bytes, > > LRA loops. Likely this causes a problem because there is no actual > > instruction for subtracting constants more than 512. However, there is a > > "link" pattern that allows this. It is puzzling. > > That "link" pattern does > > (minus (reg) (imm)) > > but that is not canonical RTL; it should be written > > (plus (reg) (-imm)) >
OK, thanks. I have corrected this. Seeing the same failure with LRA. > Compile with -da to get dump files, look at the .reload one (which is > for LRA if that is enabled), stare long and hard. I recommend coffee. OK! Looking more at this, the LRA is not actually looping on the link, but on an address calculation So this code: int runtest_bigframe() { unsigned int i; unsigned char buf[900]; for (i = 0; i < 900; i++) buf[i] = (i % 237); Causes this address calculation, attempting to compute the address of buf[]: (insn 36 30 37 2 (set (reg:SI 96) (const_int -900 [0xfffffffffffffc7c])) /home/james/tmp/x.c:11 25 {*movsi} (expr_list:REG_EQUIV (const_int -900 [0xfffffffffffffc7c]) (nil))) (insn 37 36 39 2 (set (reg:SI 97) (plus:SI (reg/f:SI 0 $fp) (reg:SI 96))) /home/james/tmp/x.c:11 2 {addsi3} (expr_list:REG_DEAD (reg:SI 96) (expr_list:REG_EQUIV (plus:SI (reg/f:SI 0 $fp) (const_int -900 [0xfffffffffffffc7c])) (nil)))) And LRA loops on insn 37, repeatedly allocating a register for (reg:SI 97). However, something like this: void foo (void) { unsigned char buf[900]; bar(buf); } Happily compiles, even though the address calculation is identical! foo: link $fp,924 ldk.l $r0,-900 add.l $r0,$fp,$r0 call bar unlink $r29 return Here is the relevant part of the dump, just before reload as above: (insn 11 6 7 2 (set (reg:SI 43) (const_int -900 [0xfffffffffffffc7c])) /home/james/tmp/x.c:31 25 {*movsi} (expr_list:REG_EQUIV (const_int -900 [0xfffffffffffffc7c]) (nil))) (insn 7 11 8 2 (set (reg:SI 2 $r0) (plus:SI (reg/f:SI 0 $fp) (reg:SI 43))) /home/james/tmp/x.c:31 2 {addsi3} (expr_list:REG_DEAD (reg:SI 43) (nil))) They look very similar. I am currently baffled. > > Do you think it would be easier to make the submission as is, then debug > > the LRA issues from that point? If so, I have attached the current patch > > set. > > You should add a -mlra option so other people can easily enable it, too; > also handy later (when it defaults to on) when LRA blows up (you can > workaround with -mno-lra then). Sounds good to me. Would that be an acceptable way to get the FT32 port into the tree? I am very happy to go with the general flow towards LRA, but at this point perhaps it may be a little early? -- James Bowman FTDI Open Source Liaison