Status of gcc 9.1.1 rev. 274208 on x86_64-w64-mingw32
Testresults can be seen here: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00909.html Complete logs of the testsuite run are available here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature
Re: Use predicates for RTL objects
On Wed, Aug 7, 2019 at 7:34 PM Segher Boessenkool wrote: > > On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: > > I would also like to get some comments on the following idea to make the > > code checks more readable: I am thinking of adding > > bool rtx_def::is_a (enum rtx_code) const > > This would allow us to make all the rtx_code comparisons more readable > > without having to define individual macros for each. > > i.e., > > REG_P (x) => x->is_a (REG) > > GET_CODE (x) == PLUS => x->is_a (PLUS) > > GET_CODE (PATTERN (x)) == SEQUENCE => PATTERN (x)->is_a (SEQUENCE) > > That makes things much worse. Not only is it less readable (IMO), but > the "is_a" idiom is used to check if something is of a certain class, > which is not the case here. > > In "GET_CODE (x) == PLUS" it is clear that what the resulting machine > code does is cheap. With "x->is_a (PLUS)", who knows what is happening > below the covers! > > (And "REG_P" and similar are much shorter code to type). Note also that in other places in GCC we use is_a (x) instead, see is-a.h. I don't welcome your member-function style style :/ Richard. > > Segher
Re: Indirect memory addresses vs. lra
On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date. So I'm not surprised it's not working. My suggestion would be to ignore the double-indirect aspect of the architecture right now, get the port working, then come back and try to make double-indirect addressing modes work. This sounds like sensible advice. However I wonder if this issue is related to the other major outstanding problem I have, viz: the large number of test failures which report "Unable to find a register to spill" - So far, nobody has been able to explain how to solve that issue and even the people who appear to be more knowlegeable have expressed suprise that it is even happening at all. Even if it should turn out not to be related, the message I've been receiving in this thread is lra should not be expected to work for non "mainstream" backends. So perhaps there is another, yet to be discovered, restriction which prevents my backend from ever working? On the other hand, given my lack of experience with gcc, it could be that lra is working perfectly, and I have simply done something incorrectly.But the uncertainty voiced in this thread means that it is hard to be sure that I'm not trying to do something which is currently unsupported. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
Hi! On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote: > On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: > > Yea, it's certainly designed with the more mainstream architectures in > mind. THe double-indirect case that's being talked about here is well > out of the mainstream and not a feature of anything LRA has targetted to > date. So I'm not surprised it's not working. > > My suggestion would be to ignore the double-indirect aspect of the > architecture right now, get the port working, then come back and try to > make double-indirect addressing modes work. > > This sounds like sensible advice. However I wonder if this issue is > related to the other major outstanding problem I have, viz: the large > number of test failures which report "Unable to find a register to > spill" - So far, nobody has been able to explain how to solve that > issue and even the people who appear to be more knowlegeable have > expressed suprise that it is even happening at all. No one is surprised. It is just the funny way that LRA says "whoops I am going in circles, there is no progress and there will never be, I'd better stop that". Everyone doing new ports / new conversions to LRA sees that error all the time. The error could be pretty much *anywhere* in your port. You have to look at what LRA did, and why, and why that is wrong, and fix that. > Even if it should turn out not to be related, the message I've been > receiving in this thread is lra should not be expected to work for > non "mainstream" backends. LRA is more likely to have problems in situations where it has not been tested before. You can replace LRA by anything else, and this isn't limited to GCC (or software, or human endeavours, or humanity even). > So perhaps there is another, yet to be > discovered, restriction which prevents my backend from ever working? >From ever? Nah, we can patch. Also, Occam's razor says there likely is an error in your backend you haven't found yet. > On the other hand, given my lack of experience with gcc, it could be > that lra is working perfectly, and I have simply done something > incorrectly.But the uncertainty voiced in this thread means that it > is hard to be sure that I'm not trying to do something which is > currently unsupported. Is your code in some branch in our git? Or in some other public git? Do you have a representative testcase? Segher
Re: Indirect memory addresses vs. lra
> On Aug 9, 2019, at 10:16 AM, Segher Boessenkool > wrote: > > Hi! > > On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote: >> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: >> >> ... However I wonder if this issue is >> related to the other major outstanding problem I have, viz: the large >> number of test failures which report "Unable to find a register to >> spill" - So far, nobody has been able to explain how to solve that >> issue and even the people who appear to be more knowlegeable have >> expressed suprise that it is even happening at all. > > No one is surprised. It is just the funny way that LRA says "whoops I > am going in circles, there is no progress and there will never be, I'd > better stop that". Everyone doing new ports / new conversions to LRA > sees that error all the time. > > The error could be pretty much *anywhere* in your port. You have to > look at what LRA did, and why, and why that is wrong, and fix that. I've run into this a number of times. The difficulty is that, for someone who understands the back end and the documented rules but not the internals of LRA, it tends to be hard to figure out what the problem is. And since the causes tend to be obscure and undocumented, I find myself having to relearn the analysis from time to time. It has been stated that LRA is more dependent on correct back end definitions than Reload is, but unfortunately the precise definition of "correct" can be less than obvious to a back end maintainer. paul
Re: Indirect memory addresses vs. lra
On 8/9/19 2:14 AM, John Darrington wrote: > On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: > > Yea, it's certainly designed with the more mainstream architectures in > mind. THe double-indirect case that's being talked about here is well > out of the mainstream and not a feature of anything LRA has targetted to > date. So I'm not surprised it's not working. > > My suggestion would be to ignore the double-indirect aspect of the > architecture right now, get the port working, then come back and try to > make double-indirect addressing modes work. > > This sounds like sensible advice. However I wonder if this issue is > related to the other major outstanding problem I have, viz: the large > number of test failures which report "Unable to find a register to > spill" - So far, nobody has been able to explain how to solve that > issue and even the people who appear to be more knowlegeable have > expressed suprise that it is even happening at all. You're going to have to debug what LRA is doing and why. There's really no short-cuts here. We can't really do it for you. Even if you weren't using LRA you'd be doing the same process, just on even more difficult to understand codebase. > > Even if it should turn out not to be related, the message I've been > receiving in this thread is lra should not be expected to work for > non "mainstream" backends. So perhaps there is another, yet to be > discovered, restriction which prevents my backend from ever working? It's possible. But that's not really any different than reload. There's certainly various aspects of architectures that reload can't handle as well -- even on architectures that were mainstream processors when reload was under active development and maintenance. THere's even a good chance reload won't handle double-indirect addressing modes well -- they were far from mainstream and as a result the code which does purport to handle double-indirect addressing modes hasn't been used/tested all that much over the last 25+ years. > > On the other hand, given my lack of experience with gcc, it could be > that lra is working perfectly, and I have simply done something > incorrectly.But the uncertainty voiced in this thread means that it > is hard to be sure that I'm not trying to do something which is > currently unsupported. My recommendation is to continue with the LRA path. jeff
Re: Indirect memory addresses vs. lra
On 2019-08-09 4:14 a.m., John Darrington wrote: On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date. So I'm not surprised it's not working. My suggestion would be to ignore the double-indirect aspect of the architecture right now, get the port working, then come back and try to make double-indirect addressing modes work. This sounds like sensible advice. However I wonder if this issue is related to the other major outstanding problem I have, viz: the large number of test failures which report "Unable to find a register to spill" - So far, nobody has been able to explain how to solve that issue and even the people who appear to be more knowlegeable have expressed suprise that it is even happening at all. Basically, LRA behaves here as older reload. If an RTL insn needs hard regs and there are no free regs, LRA/reload put pseudos assigned to hard regs and living through the insn into memory. So it is very hard to run into problem "unable to find a register to spill", if the insn needs less regs provided by architecture. That is why people are surprised. Still it can happens as one RTL insn can be implemented by a few machine insns. Most frequent case here are GCC asm insns requiring a lot of input/output/and clobbered regs/operands. If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. The less regs the architecture has, the easier to run into such error message if something described wrong in the back-end. I see your architecture is 16-bit micro-controller with only 8 regs, some of them is specialized. So your architecture is really register constrained. Even if it should turn out not to be related, the message I've been receiving in this thread is lra should not be expected to work for non "mainstream" backends. So perhaps there is another, yet to be discovered, restriction which prevents my backend from ever working? On the other hand, given my lack of experience with gcc, it could be that lra is working perfectly, and I have simply done something incorrectly.But the uncertainty voiced in this thread means that it is hard to be sure that I'm not trying to do something which is currently unsupported. LRA/reload is the most machine-dependent machine-independent pass in GCC. It is connected to machine-dependent code by numerous ways. Big part of making a new backend is to make LRA/reload and machine-dependent code communication in the right way. Sometimes it is hard to decide who is responsible for RA related bugs: RA or back-end. Sometimes an innocent change in RA solving one problem for a particular target might results in numerous new bugs for other targets. Therefore it is very difficult to say will your small change to permit indirect memory addressing work in general case.
gcc-8-20190809 is now available
Snapshot gcc-8-20190809 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190809/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 274244 You'll find: gcc-8-20190809.tar.xzComplete GCC SHA256=77d8d80c835bb4f57448cd1a9329e927952d0788974373d5b598b0a12ae3d4b9 SHA1=2b8dcdf1fa07fc5f25a4ccf4f51ac095b180e9cd Diffs from 8-20190802 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Indirect memory addresses vs. lra
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've attached such a dump (generated from gcc/testsuite/gcc.c-torture/compile/pr53410-2.c). The less regs the architecture has, thoke easier to run into such error message if something described wrong in the back-end.?? I see your architecture is 16-bit micro-controller with only 8 regs, some of them is specialized.?? So your architecture is really register constrained. That's not quite correct. It is a 24-bit micro-controller (the address space is 24 bits wide). There are 2 address registers (plus stack pointer and program counter) and there are 8 general purpose data registers (of differing sizes). J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. Building IRA IR Pass 0 for finding pseudo/allocno costs r36: preferred X_REG, alternative NO_REGS, allocno X_REG a0 (r36,l0) best X_REG, allocno X_REG r35: preferred X_REG, alternative NO_REGS, allocno X_REG a10 (r35,l0) best X_REG, allocno X_REG r34: preferred X_REG, alternative NO_REGS, allocno X_REG a1 (r34,l0) best X_REG, allocno X_REG r33: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a11 (r33,l0) best DATA_REGS, allocno DATA_REGS r32: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a12 (r32,l0) best DATA_REGS, allocno DATA_REGS r31: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a14 (r31,l0) best DATA_REGS, allocno DATA_REGS r30: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS a13 (r30,l0) best NO_REGS, allocno NO_REGS r29: preferred X_REG, alternative NO_REGS, allocno X_REG a15 (r29,l0) best X_REG, allocno X_REG r28: preferred X_REG, alternative NO_REGS, allocno X_REG a16 (r28,l0) best X_REG, allocno X_REG r27: preferred X_REG, alternative NO_REGS, allocno X_REG a17 (r27,l0) best X_REG, allocno X_REG r26: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a2 (r26,l0) best DATA_REGS, allocno DATA_REGS r25: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a4 (r25,l0) best DATA_REGS, allocno DATA_REGS r24: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a3 (r24,l0) best DATA_REGS, allocno DATA_REGS r23: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a5 (r23,l0) best DATA_REGS, allocno DATA_REGS r22: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a6 (r22,l0) best DATA_REGS, allocno DATA_REGS r21: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a8 (r21,l0) best DATA_REGS, allocno DATA_REGS r20: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a7 (r20,l0) best DATA_REGS, allocno DATA_REGS r19: preferred DATA_REGS, alternative NO_REGS, allocno DATA_REGS a9 (r19,l0) best DATA_REGS, allocno DATA_REGS a0(r36,l0) costs: X_REG:0 MEM:5000 a1(r34,l0) costs: X_REG:0 MEM:84000 a2(r26,l0) costs: DATA_REGS:0 MEM:5000 a3(r24,l0) costs: DATA_REGS:0 MEM:5000 a4(r25,l0) costs: DATA_REGS:0 MEM:5000 a5(r23,l0) costs: DATA_REGS:0 MEM:5000 a6(r22,l0) costs: DATA_REGS:0 MEM:5000 a7(r20,l0) costs: DATA_REGS:0 MEM:5000 a8(r21,l0) costs: DATA_REGS:0 MEM:5000 a9(r19,l0) costs: DATA_REGS:0 MEM:5000 a10(r35,l0) costs: X_REG:0 MEM:5000 a11(r33,l0) costs: DATA_REGS:0 MEM:8000 a12(r32,l0) costs: DATA_REGS:0 MEM:7000 a13(r30,l0) costs: MEM:8000 a14(r31,l0) costs: DATA_REGS:0 MEM:7000 a15(r29,l0) costs: X_REG:0 MEM:8000 a16(r28,l0) costs: X_REG:0 MEM:8000 a17(r27,l0) costs: X_REG:2000 MEM:8000 Insn 43(l0): point = 0 Insn 39(l0): point = 3 Insn 38(l0): point = 5 Insn 37(l0): point = 7 Insn 36(l0): point = 9 Insn 35(l0): point = 11 Insn 34(l0): point = 13 Insn 33(l0): point = 15 Insn 32(l0): point = 17 Insn 31(l0): point = 19 Insn 30(l0): point = 21 Insn 29(l0): point = 23 Insn 28(l0): point = 25 Insn 27(l0): point = 27 Insn 26(l0): point = 29 Insn 25(l0): point = 31 Insn 24(l0): point = 33 Insn 23(l0): point = 35 Insn 22(l0): point = 37 Insn 21(l0): point = 39 Insn 20(l0): point = 41 Insn 19(l0): point = 43 Insn 18(l0): point = 45 Insn 17(l0): point = 47 Insn 16(l0): point = 49 Insn 15(l0): point = 51 Insn 14(l0): point = 53 Insn 9(l0): point = 55 Insn 8(l0): point = 57 Insn 7(l0): point = 59 Insn 6(l0): point = 61 Insn 5(l0): point = 63 Insn 4(l0): point = 65 Insn 3(l0): point = 67 Insn 2(l0): point = 69 Insn 10(l0): point = 71 a0(r36): [4..5] a1(r34): [4..55] a2(r26): [18..21] a3(r24): [20..25] a4(r25): [22..23] a5(r23): [26..27] a6(r22):
Re: Indirect memory addresses vs. lra
On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote: Is your code in some branch in our git? No. But it could be pushed there if people think it would be appropriate to do so, and if I'm given the permissions to do so. Or in some other public git? It's in my repo on gcc135 ~jmd/gcc-s12z (branch s12z) Do you have a representative testcase? I think gcc/testsuite/gcc.c-torture/compile/pr53410-2.c is as representative as any. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: PGP signature
Using gcc/ChangeLog instead of gcc/testsuite/ChangeLog?
Has there been a change of policy so it's a valid option to use gcc/ChangeLog for testsuite changes? I was about to move a semi-randomly spotted misplaced entry, and when checking if there were others, I noticed that there's like tens of them, so I thought better ask. (IMHO it's confusing to have to inspect more than one ChangeLog, but I'm not going to bother changing anything if that's not the common view.) brgds, H-P
