Plus Reload
Hi, I have a question regarding Plus reload situation I ran into in my port (which was taken from branch 4.6): I got the following insn: Set d1 (plus r1 -96). d1 and r1 are 2 registers from different classes. The reload (which take place at: reload1.c , gen_reload(out = d1, in = (plus r1 -96)) try 3 options: 1. switch the plus operands: set d1 (plus -96 r1) 2. split into 2 insns - reload the const to d1 and then add r1: set d1 -96 set d1 (plus d1 r1) 3. split into 2 insns - copy r1 to d1 and then add the const: set d1 r1 set d1 (plus d1 -96) GCC tries generating the 1st option - and fails since no valid pattern is found. Then it tries generating the 2nd option and fails once again, since no valid pattern is found. Then it tries generating the 3rd option without constraint validity check(emit_insn_if_valid_for_reload) like the first 2 attempts, and creates a new insn which will later fail since it's not satisfying it's constraints. My question is: why is GCC certain that one of those 3 attempts must work? In my case, all 3 resulted insns are not supported by the architecture. Thanks, Gidi.
Re: Plus Reload
Hi Ian, Relevant instruction supported: add r,r,r add r,r unsigned add r,r, signed add d,d,d add d,d unsigned Thanks, Gal. On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> I have a question regarding Plus reload situation I ran into in my >> port (which was taken from branch 4.6): >> >> I got the following insn: Set d1 (plus r1 -96). >> d1 and r1 are 2 registers from different classes. >> >> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >> (plus r1 -96)) try 3 options: >> >> 1. switch the plus operands: >> set d1 (plus -96 r1) >> >> 2. split into 2 insns - reload the const to d1 and then add r1: >> set d1 -96 >> set d1 (plus d1 r1) >> >> 3. split into 2 insns - copy r1 to d1 and then add the const: >> set d1 r1 >> set d1 (plus d1 -96) >> >> GCC tries generating the 1st option - and fails since no valid pattern is >> found. >> Then it tries generating the 2nd option and fails once again, since no >> valid pattern is found. >> Then it tries generating the 3rd option without constraint validity >> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >> and creates a new insn which will later fail since it's not satisfying >> it's constraints. >> >> My question is: why is GCC certain that one of those 3 attempts must work? >> In my case, all 3 resulted insns are not supported by the architecture. > > What instructions are supported by your processor here? > > Ian >
Re: Plus Reload
oh, I forgot: move d,r(d = r) On Tue, Jan 11, 2011 at 4:59 PM, Gidi Nave wrote: > Hi Ian, > > Relevant instruction supported: > > add r,r,r > add r,r unsigned > add r,r, signed > add d,d,d > add d,d unsigned > > Thanks, > Gal. > > > On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: >> Gidi Nave writes: >> >>> I have a question regarding Plus reload situation I ran into in my >>> port (which was taken from branch 4.6): >>> >>> I got the following insn: Set d1 (plus r1 -96). >>> d1 and r1 are 2 registers from different classes. >>> >>> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >>> (plus r1 -96)) try 3 options: >>> >>> 1. switch the plus operands: >>> set d1 (plus -96 r1) >>> >>> 2. split into 2 insns - reload the const to d1 and then add r1: >>> set d1 -96 >>> set d1 (plus d1 r1) >>> >>> 3. split into 2 insns - copy r1 to d1 and then add the const: >>> set d1 r1 >>> set d1 (plus d1 -96) >>> >>> GCC tries generating the 1st option - and fails since no valid pattern is >>> found. >>> Then it tries generating the 2nd option and fails once again, since no >>> valid pattern is found. >>> Then it tries generating the 3rd option without constraint validity >>> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >>> and creates a new insn which will later fail since it's not satisfying >>> it's constraints. >>> >>> My question is: why is GCC certain that one of those 3 attempts must work? >>> In my case, all 3 resulted insns are not supported by the architecture. >> >> What instructions are supported by your processor here? >> >> Ian >> >
Re: Plus Reload
because it's:add d,d unsigned we don't have: add d,d signed and in this case we need: d = r + (-96) On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: >>> Gidi Nave writes: >>> >>>> I have a question regarding Plus reload situation I ran into in my >>>> port (which was taken from branch 4.6): >>>> >>>> I got the following insn: Set d1 (plus r1 -96). >>>> d1 and r1 are 2 registers from different classes. >>>> >>>> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >>>> (plus r1 -96)) try 3 options: >>>> >>>> 1. switch the plus operands: >>>> set d1 (plus -96 r1) >>>> >>>> 2. split into 2 insns - reload the const to d1 and then add r1: >>>> set d1 -96 >>>> set d1 (plus d1 r1) >>>> >>>> 3. split into 2 insns - copy r1 to d1 and then add the const: >>>> set d1 r1 >>>> set d1 (plus d1 -96) >>>> >>>> GCC tries generating the 1st option - and fails since no valid pattern is >>>> found. >>>> Then it tries generating the 2nd option and fails once again, since no >>>> valid pattern is found. >>>> Then it tries generating the 3rd option without constraint validity >>>> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >>>> and creates a new insn which will later fail since it's not satisfying >>>> it's constraints. >>>> >>>> My question is: why is GCC certain that one of those 3 attempts must work? >>>> In my case, all 3 resulted insns are not supported by the architecture. >>> >>> What instructions are supported by your processor here? >> >> Relevant instruction supported: >> >> add r,r,r >> add r,r unsigned >> add r,r, signed >> add d,d,d >> add d,d unsigned > > So why doesn't d1 = d1 + -96 match the last instruction there? > > Ian >
Re: Plus Reload
On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: >> >>> So why doesn't d1 = d1 + -96 match the last instruction there? >>> >> because it's: add d,d unsigned >> we don't have: add d,d signed >> >> and in this case we need: d = r + (-96) > > (Please don't top-post on this mailing list. Thanks.) > > Addition of signed and unsigned numbers is the same operation at the > machine level. Are there limitations on the signed value? If so, is > there is a sub instruction? > > Ian > Hi Ian, There are limitation for the signed value for D class registers. There is a sub instruction for D registers, but it's limited to U5 (unsigned of 5 bits) which is not the case here. Thanks, Gidi.
Re: Plus Reload
On Wed, Jan 12, 2011 at 8:27 AM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor wrote: >>> Gidi Nave writes: >>> >>>> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: >>>> >>>>> So why doesn't d1 = d1 + -96 match the last instruction there? >>>>> >>>> because it's: add d,d unsigned >>>> we don't have: add d,d signed >>>> >>>> and in this case we need: d = r + (-96) >>> >>> Addition of signed and unsigned numbers is the same operation at the >>> machine level. Are there limitations on the signed value? If so, is >>> there is a sub instruction? >> >> There are limitation for the signed value for D class registers. >> There is a sub instruction for D registers, but it's limited to U5 >> (unsigned of 5 bits) which is not the case here. > > Thanks. Since we don't know the details of your processor, we could be > more helpful if you provided this sort of information up front. It > sounds like you are saying that there is no way to subtract 96 without > using an extra register. Is that correct? > > If that is the case, then I agree with Jeff that you are going to need > to define a secondary reload. Look at TARGET_SECONDARY_RELOAD in the > docs. > > By the way, if the restrictions on addition (which you did not describe) > are less severe than the restrictions on subtraction, then you should > consider adjusting your frame pointer so that most stack slots are at a > positive offset rather than a negative one. I don't know if that is > what is going on here, though a negative offset is certainly unusual. > > Ian > Hi Ian, There is no way to subtract 96 without the extra register. The secondary reload worked great !!! Thanks! Regarding the frame pointer - in my case it was the frame pointer but our addition/subtract instructions options are similar (for the same register classes), so adjusting the frame pointer won't do any good. One more question: GCC usually knows how to handle cases which need decomposition of expressions due to architecture limitations. In my case it didn't know. How can I foreseen additional such cases, in order to avoid compilation crush? Thanks, Gidi.
Re: Plus Reload
On Wed, Jan 12, 2011 at 3:50 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/12/11 01:45, Gidi Nave wrote: > >> >> One more question: >> GCC usually knows how to handle cases which need decomposition of >> expressions due to architecture limitations. >> In my case it didn't know. >> How can I foreseen additional such cases, in order to avoid compilation >> crush? > I'm not sure there is a reasonable way other than experience and > intimate knowledge of how reload works. > > I haven't done any measurements, but I see more questions/issues being > raised by developers doing their own ports with regards to reloading > than any other part of the compiler. > > That's no great surprise, since reload is probably the nastiest pass of > the compiler and even those of us with significant experience still > struggle with corner case reload problems. > > jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNLbGiAAoJEBRtltQi2kC75ngIAKJJhYdYgQV2l0LsZCxUbhb9 > OxHXr2CBbEZgpT6VRIrTJnJ51QEjxscLCBo0Ip/ZnpMiulb5S+hmyjrQJxXxEyPI > pF64uV6Gla0qcGgABrVkPWi6UEPDpvkrD0mljpcsqdK6tYtPFIww8sYMC+LecdUM > GMan7eXcKxgVu51c2xkp57afg9xuVcZXwHAcME74MkYC37vT0KGAPKpRIBum+ues > PL+2hOfa7wzQ6SbM9d7sVrU4o029IzWEgPPYwWVrw0NSQlIHbAnOf6Q0V+Y9jeeb > M36Vh/ynzExLmFq1kmESTEeOAqEg9r97mwaiaXPK4vYZEc3r9YMjq1rRUhEFO48= > =6tO+ > -END PGP SIGNATURE- > Ok, Thanks for the help! Gidi.
Re: Plus Reload
On Wed, Jan 12, 2011 at 6:36 PM, Dave Korn wrote: > On 12/01/2011 13:50, Jeff Law wrote: > >> On 01/12/11 01:45, Gidi Nave wrote: >> >>> One more question: >>> GCC usually knows how to handle cases which need decomposition of >>> expressions due to architecture limitations. >>> In my case it didn't know. >>> How can I foreseen additional such cases, in order to avoid compilation >>> crush? >> I'm not sure there is a reasonable way other than experience and >> intimate knowledge of how reload works. > > If your port makes it all the way through the testsuite without any ICEs, > you can feel at least /statistically/ re-assured that it's not likely to run > into problems during regular day-to-day use. > > cheers, > DaveK > > Actually, this issue was found while running my testsuite... Thanks, Gidi.
