> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can't figure out at all. I'm hoping for some help or hints to track
>> down the cause and come up with a fix.
>>
>> The failing program is testsuite/gcc.c-torture/compile/ifreg.c:
>
> [ snip ]
>
>> I don't know how to read that, and I don't know what to look for to find a
>> cause or a cure. Apart from turning on LRA, the code I'm running is what's
>> in the repository, if anyone wants to look at the md file or other bits to
>> offer suggestions.
>
> I think this is because the PDP port still has subregs of memory. You
> can get rid of that by defining some (trivial) scheduling.
I did so, and insn-attr-common.h now says:
#define INSN_SCHEDULING
But the bug is still there, unchanged.
The input insn that sends LRA into an infinite loop isn't a memory subreg; the
ira dump file shows it this way:
(insn 18 22 19 2 (set (subreg:HI (reg/v:DI 26 [ b ]) 0)
(const_int 0 [0]))
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
(nil))
So a subreg set to zero. And in the reload dump it shows this way:
(insn 18 22 25 2 (set (reg:HI 32)
(const_int 0 [0]))
"../../gcc/gcc/testsuite/gcc.c-torture/compile/ifreg.c":10 21 {movhi}
(nil))
which makes sense given that the register width (word width) is 2. But that's
the insn that is then followed by an infinite number of register copy
operations.
paul
