On 08/20/2018 10:50 AM, Paul Koning wrote: > > >> 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 don't know what the port does that enables memory subregs. If I read > gccint correctly, just turning on scheduling should make them go away? Ok, > adding scheduling was on my list anyway; pdp11s with float are dual pipe > machines so it's actually a meaningful thing to do. > > The internals manual seems to say that memory subregs are an old mechanism > that should still work, give or take. If indeed it breaks LRA perhaps the > documentation should be updated to say that it is an obsolete mechanism that > no longer works and needs to be disabled. It's definitely not something we encourage. But many of the older ports allow them.
Essentially we know that subreg-mem will always need reloading. We want to expose those insns to the first scheduling pass, so we don't create them when the port has any scheduling bits defined. Even just a dummy "everything is one cycle" description is sufficient. I'm not aware of anything that says you can't do subreg-mem with LRA. It may be the case that you're dealing with the first port that's tripped over this. jeff
