Re: GCC association with the FSF
On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote: > It reflects the same message that has been sent to new GNU > maintainers > for the decades. The GNU structure and organization document > (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a > reflection of that, and how we have been doing things for decades. "We've always done it this way" is not necessarily a good defence of an existing practice. You are right. The GNU Structure document doesn't claim to be. It just documents the way things are. > That is true, RMS appoints which projects become GNU projects or not, > and who maintains them. And as maintainers we have a lot of freedom, > as > can be seen here, and elsewhere. What you're describing sounds like a dictatorship to me. I cannot see how you reach that conclusion. I don't think you get to speak for who is or is not a member of the GNU project. As far as I know, "GNU" isn't trademarked. It certainly used to be, unless those guys at the FSF have let it lapse again. J'
Re: GCC association with the FSF
On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote: > > What you're describing sounds like a dictatorship to me. > > I cannot see how you reach that conclusion. Having one guy at the top from whom all power flows. Power does not "flow" from RMS. Since you have used a political analogy: I think it is more akin to a constitutional monarchy. What's the process for replacing the guy at the top, if he's become a liability to the project? What would a healthy structure look like? Many countries have a single person as head of state with no formally defined process for replacing him or her. Most of those countries are not usually descibed as "dictatorships". Further, history has shown, in cases where that head of state has been forcibly removed (eg France, Russia). the regime that replaced them turned out to be composed of murderous powermongers concerned with nobody's interest but their own. I for one, will not sit back and let that heppen to GNU. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 07:56:14AM -0400, Richard Kenner wrote: > Having one guy at the top from whom all power flows. > > Power does not "flow" from RMS. Since you have used a political analogy: > I think it is more akin to a constitutional monarchy. I think it's like the Queen of England. As a British person I used to know said: "The Queen of England has the power to veto anything passed by the Parliament in any Commonwealth country until she actually does it; at that point she'll lose that power". In 1975 she dismissed the prime minister of Australia, yet nearly 50 years later she is still the head of state. I see it as the same here: if RMS tried to exert an inappropriate level of control over some GNU project, it would soon be made clear that that something he can't do. Generally I agree. Such draconian measures like dismissal of people has to be done tactfully, only occasionally and only when there is very good cause. So far as I'm aware, her majesty has done it only once; rms has done it only twice. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote: I think it's important to distinguish between the figurative and literal here. No one is literally calling for anyone's head. Nobody has explicitly done so. However in the last 2 or 3 years there has been a growing campaign of hatred. The people feeding that campaign are unhappy with things that RMS and others have said. However they have taken it further than that. These people seek eliminate *anyone* who holds certain opinions - they don't care how they get eliminated - so long as they go. What's more, they cite numerous putative moralistic justifications to give an air of legitmacy to that hatred. Once such hatefulness becomes accepted, people DON'T any longer make that literal--figurative distinction. Some of us don't want RMS in a leadership position in a project we're associated with (be it the FSF or GNU, and thus, GCC). RMS was the first person to be involved in GNU and GCC. Others became involved later (under his leadership). Their contribution was and continues to be welcome. They are also free to stop contributing any time they wish to do so. My opinions, not my employer's, as usual. Then why do you write this from your employer's email? That is like writing it on the company letterhead. I suggest that when speaking for yourself you use your own email. J'
Re: GCC association with the FSF
On Thu, Apr 08, 2021 at 09:35:23PM -0400, David Malcolm wrote: > RMS was the first person to be involved in GNU and GCC. Others > became > involved later (under his leadership). Their contribution was and > continues to be welcome. They are also free to stop contributing any > time they wish to do so. I intend to continue contributing to GCC (and to Free Software in general), but RMS is not my leader. Nobody is suggesting that RMS should be regarded by everyone or indeed anyone as "mein Führer". I think he would be very much concerned if anyone tried to confer a cult hero status on him. Sooner or later, if for no reason other than his age, RMS will have to step down as leader of GNU. Rather than calling for his head on a block it would be more constructive to think to the future. Unfortunately to date, I have not seen anyone who in my opinion would have the qualities necessary to take over the role. > Then why do you write this from your employer's email? My employer gives me permission. That's good to know. My employer on the other hand expressly forbids it. And I think that is a reasonable prohibition (we're allowed to use their internet connection for personal use) but not allowed to use the company name (including email addresses) in personal communication. Even if they didn't prohibit this, I wouldn't dream of using my company's email or letterhead for personal communication. Given the reaction that some have faced for questioning RMS, I'd prefer to keep that address private. So in other words, you are happy to make contraversial statements, but don't wish to face the responsibility. Come on David! By all means question RMS (or anyone else) but have the guts to do this under your own identity rather than duck in and out behind a veil of quasi-anonymity! I'm glad that you're going to continue to contribute to GCC. J'
Re: GCC association with the FSF
On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: Different opinions are fine. Bringing national or international politics into the discussion (presumably meant to be as an insult) is not fine. This is not a political discussion - please stop trying to make it one. For the record it was David who first brought up the political allegory so this comment should be directed in his direction. As for your second point, I find it disappointing but not suprising that you "presumed" this comment to be an insult. This is precisely the thing which has caused so much poisonous discourse in recent years. Some people take any opinion they disagree with and look for ways to interpret it as an insult. This gives them a lever to claim that anyone who holds that opinion is a chauvanist, a bigot or worse. This must stop.
Re: GCC association with the FSF
On Sat, Apr 10, 2021 at 01:50:42PM +0100, Bronek Kozicki via Gcc wrote: I would very much prefer if a person who openly expressed opinions, and also openly exercised behaviours, which I consider abhorrent, was *not* associated with the GCC project. It does not matter to me what kind of control that person exerts on the project, if any. What matters to me is association, even if indirect one (other than historical). I suppose I feel the same. I would also prefer it if all people involved with GCC (and all my other interests) did not do or say things which made me uncomfortable. I don't however feel that I have the right to call for anyone to be excluded simply because I'm uncomfortable with that person's words or deeds (ie. "consider them abhorent"). That would be an utterly dystopian, world. Of course persons should not use a project's name or infrastructure to make comments unrelated to the project. But if that person wishes to make a comment under his/her own name in an unrelated forum, that is his/her right. Even if we consider them abhorrent, we must respect the rights of others. J'
Re: GCC association with the FSF
On Sun, Apr 11, 2021 at 12:30:41AM +0200, Gerald Pfeifer wrote: There are a number of people arguing here who have contributed little to nothing to GCC, whose names even did not trigger memories - unlike David M. or Jonathan, for example, or Nathan or Alexandre. For myself, I have been a long term user/contributor to GCC albiet hardly in a major role. I don't think I've ever posted to this list until a few days ago, when all of a sudden these messages started popping up in my inbox. So either I subscribed to this list many years ago and it has been dormant until recently or someone subscribed me just recently. When it comes to deciding the direction of a project like GCC - technical and otherwise - in my mind it primarily should be those actually involved and contributing. I disagree. The principle by which high level decisions in all GNU projects have always been made is how it best helps the GNU system as a whole. Contributors are exactly that. They offer *contributions* - the very meaning of the word implies there is no expectation of anything in return. Obviously I hope all contributors *do* get some satisfaction and maybe even some tangible benefit. But contributions are not to be seen as a means to gain control of the project at a high level. J'
Re: GCC association with the FSF
On Sun, Apr 11, 2021 at 09:30:48AM -0400, Richard Kenner via Gcc wrote: > > When it comes to deciding the direction of a project like GCC - technical > > and otherwise - in my mind it primarily should be those actually involved > > and contributing. > > GNU follows the general principle of the Free Software movement, that > freedom for *users* is the priority. Assigning *higher* importance to > developers' preferences is *not* a position I share. I think there's a difference between philosophy and practicality here. Sure, the importance of work done by different developers, measured on the scale of advancing the goals of the Free Software movement, is different for each. But what actually advances a project (which can be viewed as "deciding [its] direction") is what work developers choose to do, not the importance of each piece of work on that metric. I guess my point is that the direction in which a project *does* go is not always the direction in which it *should* go. I conceed that the converse is also true: Technical experts are very useful for putting the brakes on Joe Average User's crazy ideas when they are doomed to failure from the outset. So I certainly agree with what you said above, but don't think that changes the reality that it's ultimately what developers choose to work on that most affects the direction of a project. That indeed is often the reality, but equally as often *not* what is desired. To give just one small practical example, I'm told (by people who are more familiar with GCC internals than I) that it is not feasible with today's GCC to port to backends which have a small number of registers. This has meant that whole familys of CPUs work only with proprietary compilers. J'
Re: GCC association with the FSF
41;344;0cOn Sun, Apr 11, 2021 at 07:30:13PM -0300, Adhemerval Zanella via Gcc wrote: And there was no hate (at least not from my side) only *disappointment* that you used your status to do it even though most of senior developers and maintainers said explicitly you shouldn’t do it. In GNU, there are no "senior" (or junior) developers/maintainers. Maintainers have some specific responsibilities, with which developers are not emcumbered. In almost all projects, the maintainers are also developers, but this need not be the case. But all maintainers are equal, and all developers are equal. J'
Indirect memory addresses vs. lra
I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]). This arch accepts indirect memory addresses. That is to
say, those of the form (mem (mem (...))) and although my
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on reloading them out of
existence.
For example, when compiling a code fragment:
volatile unsigned char *led = 0x2F2;
*led = 1;
the ira dump file shows:
(insn 7 6 8 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 8 7 14 2 (set (mem/v:QI (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) [0
*led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
which is a perfectly valid insn, and the most efficient assembler for it is:
mov.p #0x2f2, y
mov.b #1, [0,y]
However the reload dump shows this has been changed to:
(insn 7 6 22 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])
(const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movpsi}
(nil))
(insn 22 7 8 2 (set (reg:PSI 8 x [22])
(mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]))
"/home/jmd/MemMem/memmem.c":16:8 96 {movpsi}
(nil))
(insn 8 22 14 2 (set (mem/v:QI (reg:PSI 8 x [22]) [0 *led_7+0 S1 A8])
(const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi}
(nil))
and ends up as:
mov.p #0x2f2, y
mov.p (0,y) x
mov.b #1, (0,x)
So this wastes a register (which leads to other issues which I don't want to go
into in this email).
After a lot of debugging I tracked down the part of lra which is doing this
reload to the function process_addr_reg at lra-constraints.c:1378
if (! REG_P (reg))
{
if (check_only_p)
return true;
/* Always reload memory in an address even if the target supports such
addresses. */
new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl, "address");
before_p = true;
}
Changing this to
if (! REG_P (reg))
{
if (check_only_p)
return true;
return false;
}
solves my immediate problem. However I imagine there was a reason for doing
this reload, and presumably a better way of avoiding it.
Can someone explain the reason for this reload, and how I can best ensure that
indirect memory operands are left in the compiled code?
[1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf
--
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
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
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
Re: Indirect memory addresses vs. lra
On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote:
Hi!
On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote:
> Choosing alt 5 in insn 14: (0) m (1) m {*movsi}
>14: [r40:PSI+0x20]=[r41:PSI]
> Inserting insn reload before:
>48: r40:PSI=r34:PSI
>49: r41:PSI=[y:PSI+0x2f]
insn 14 is a mem-to-mem move (another feature not many more modern /
more RISCy CPUs have). That requires both of your address registers.
So far, so good. The reloads (insn 48 and 49) require address
registers themselves; that isn't necessarily a problem either.
So far as I can see, insn 48 is completely redundant. It's copying a
pseudo reg (74) into another pseudo reg (40).
This is pointless and a waste, since insn 14 does not modify 74.
I don't understand why lra feels the need to do it.
If lra knew about (mem (mem ...)) style addressing, then insn 49 would
also be redundant (which is why I raised the topic).
In summary, what we have is:
(insn 48 84 49 2 (set (reg/f:PSI 40 [34])
(reg/f:PSI 74 [34]))
(nil))
(insn 49 48 14 2 (set (reg:PSI 41)
(mem/f/c:PSI (plus:PSI (reg/f:PSI 9 y)
(const_int 47 [0x2f])) [3 p+0 S4 A8]))
(nil))
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
where, like you say, insns 48 and 49 are reloads. But these two reloads
are unnecessary and cause the machine to run out of PSImode registers.
The above could be easier and more efficiently done simply as:
(insn 14 11 15 2 (set
(mem:SI (plus:PSI (reg/f:PSI 74 [34]) (const_int 32 [0x20])) [2 S4
A64])
(mem/f/c:PSI (mem:PSI (plus:PSI (reg/f:PSI 9 y)
(const_int 47 [0x2f])) [3 p+0 S4 A8])))
This is exactly what we had before lra messed with things. It can be
represented in the ISA with one assembler instruction:
mov.p (32, x), [47, y]
and if I'm not mistaken, alternative 5 of my "movpsi" pattern should do
this just fine.
But
this requires careful juggling. Maybe you will need some backend code
Could you give a hint into which set of hooks/constraints/predicates
this backend code should go?
--
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
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote:
Thank you for providing the sources.?? It helped me to understand what is
going on.?? So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In
function ???f1???:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95
{*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Thanks for taking a look.
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is
defined as a hard reg pointer pointer.
That is correct.
Honestly, I never saw a target with such register constraints.
My recollection is that MC68HC11 was the same.
So what can be done, imho. The simplest solution would be preventing
insns with more one memory operand.
I tried this solution earlier. But unfortunately it makes things worse. What
happens is it libgcc cannot
even be built -- ICEs occur on a memory from address reg insn such as:
(insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
(const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
(reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
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
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote: Couldn't we spill the frame pointer? Basically we should be able to compute the first address into a reg, spill that, do the second (both could require the frame pointer), spill the frame pointer, reload the first computed address from the stack, execute the insn and then reload the frame pointer. Maybe the frame pointer can also be implemented 'virually' in an index register that you keep updated so that sp + reg Is the FP. Or frame accesses can use a Stack slot as FP and the indirect memory Addressing... (is there an indirect lea?) Yes. lea x, [4,x] is a valid instruction. 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.
Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote:
> I tried this solution earlier. But unfortunately it makes things worse.
What happens is it libgcc cannot
> even be built -- ICEs occur on a memory from address reg insn such as:
> (insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
> (const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
> (reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
>
I see.?? Then for the insn, you could try to create a pattern
"memory,special memory constraint".?? The special memory constraint
should satisfy only spilled pseudo (pseudo with reg_renumber == -1).?? I
believe lra-constraints.c can spill the pseudo and the end you will have
mem[disp1 + r8|r9|sp] = mem[disp1+sp].
You mean something like this:
(define_special_memory_constraint "a"
"My special memory constraint"
(match_operand 0 "my_special_predicate")
)
(define_predicate "my_special_predicate"
(match_operand 0 "memory_operand")
{
debug_rtx (op);
if (MEM_P (op))
{
op = XEXP (op, 0);
if (GET_CODE (op) == PLUS)
{
op = XEXP (op, 0);
if (REG_P (op))
{
fprintf (stderr, "Reg number is %d\n", REGNO (op));
if (REGNO (op) >= 0)
return false;
}
}
}
return true;
})
When I use this I get lots of the following ICEs
"internal compiler error: maximum number of generated reload insns per
insn achieved (90)"
It seems logical to me that this would happen since the constraint is not going
to match any
operand with resolved registers. Thus it will continually reload.
... which makes me think I've probably misunderstood what you are saying.
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: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
{
if (lra_in_progress_p)
return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER &&
reg_renumber[REGNO(op)] < 0;
return true if memory with sp addressing;
})
I think LRA spills pseudo-register and it will be memory addressed by sp
at the end of LRA.
What I've done is this:
(define_predicate "my_special_predicate"
(match_operand 0 "memory_operand")
{
debug_rtx (op);
gcc_assert (MEM_P (op));
op = XEXP (op, 0);
if (GET_CODE (op) == PLUS)
op = XEXP (op, 0);
if (lra_in_progress)
{
fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER &&
reg_renumber[REGNO(op)] < 0;
}
if (REG_P (op))
{
int regno = REGNO (op);
return (regno == 10); // register is the stack pointer
}
return true;
})
(and many variations) Unfortunately, any moderately complicated input
still results in a (mem (reg) ) insn repeatedly entering the
lra_in_progress case and returning false, and eventually terminating with
"internal compiler error: maximum number of generated reload insns per insn
achieved (90)"
Any other ideas?
J'
Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote: > ? As I remember there were a few other ideas from Richard Biener and > Segher Boessenkool.? I also proposed to add a new address register which > will be always a fixed stack memory slot at the end. Unfortunately I am > not familiar with the target and the port to say in details how to do > it.? But I think it is worth to try. The m68hc11 port used the fake Z register approach, and I believe it had some special machine pass to get rid of it right before assembler output. (r171302 is when it was removed -- last version was https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68hc11/m68hc11.c;h=1e414102c3f1fed985e4fb8db7954342e965190b;hb=bae8bb65d842d7ffefe990c1f0ac004491f3c105#l4061 for the machine reorg stuff). No idea how well it works... But it's only needed if you are forced to have a frame pointer IIUC? Segher Most of these suggestions involve adding some sort of virtual registers So I hacked the machine description to add two new registers Z1 and Z2 with the same mode as X and Y. Obviously the assembler balks at this. However the compiler still ICEs at the same place as before. So this suggests that our original diagnosis, viz: there are not enough address registers was not accurate, and in fact there is some other problem? 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: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]
On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote: > Most of these suggestions involve adding some sort of virtual registers > So I hacked the machine description to add two new registers Z1 and Z2 > with the same mode as X and Y. > > Obviously the assembler balks at this. However the compiler still > ICEs at the same place as before. > > So this suggests that our original diagnosis, viz: there are not enough > address registers was not accurate, and in fact there is some other > problem? That sounds likely. Given you have indirect addressing you could simulate N virtual regs by placing them in a virtual reg table in memory and accessed via a fixed address register (assuming all instructions that would need an address reg also can take that indirect from memory). That was my plan. Accordingly, extending the md to provide N additional regs (N currently = 2) was the first step. Having doubled the number of available address registers, I had expected this would fix most of the ICEs (but cause a lot of assembler errors). However it hasn't eliminated any ICEs. lra is still complaining "unable to find a register to spill" So the plan seems to have fallen over at the first hurdle. Why can it still not spill registers despite having a lot more of them? J'
