* Re: Plus Reload
2011-01-11 14:59 ` Gidi Nave
@ 2011-01-11 15:02 ` Gidi Nave
2011-01-11 15:34 ` Ian Lance Taylor
2011-01-11 15:34 ` Jeff Law
2 siblings, 0 replies; 15+ messages in thread
From: Gidi Nave @ 2011-01-11 15:02 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
oh,
I forgot:
move d,r (d = r)
On Tue, Jan 11, 2011 at 4:59 PM, Gidi Nave <gidi.nave.1@gmail.com> 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 <iant@google.com> wrote:
>> Gidi Nave <gidi.nave.1@gmail.com> 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
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-11 14:59 ` Gidi Nave
2011-01-11 15:02 ` Gidi Nave
@ 2011-01-11 15:34 ` Ian Lance Taylor
2011-01-11 16:03 ` Gidi Nave
2011-01-11 15:34 ` Jeff Law
2 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 2011-01-11 15:34 UTC (permalink / raw)
To: Gidi Nave; +Cc: gcc
Gidi Nave <gidi.nave.1@gmail.com> writes:
> On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Gidi Nave <gidi.nave.1@gmail.com> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-11 15:34 ` Ian Lance Taylor
@ 2011-01-11 16:03 ` Gidi Nave
2011-01-11 17:22 ` Ian Lance Taylor
0 siblings, 1 reply; 15+ messages in thread
From: Gidi Nave @ 2011-01-11 16:03 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
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 <iant@google.com> wrote:
> Gidi Nave <gidi.nave.1@gmail.com> writes:
>
>> On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> Gidi Nave <gidi.nave.1@gmail.com> 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
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-11 16:03 ` Gidi Nave
@ 2011-01-11 17:22 ` Ian Lance Taylor
2011-01-12 6:04 ` Gidi Nave
0 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 2011-01-11 17:22 UTC (permalink / raw)
To: Gidi Nave; +Cc: gcc
Gidi Nave <gidi.nave.1@gmail.com> writes:
> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor <iant@google.com> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-11 17:22 ` Ian Lance Taylor
@ 2011-01-12 6:04 ` Gidi Nave
2011-01-12 6:28 ` Ian Lance Taylor
0 siblings, 1 reply; 15+ messages in thread
From: Gidi Nave @ 2011-01-12 6:04 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor <iant@google.com> wrote:
> Gidi Nave <gidi.nave.1@gmail.com> writes:
>
>> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor <iant@google.com> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-12 6:04 ` Gidi Nave
@ 2011-01-12 6:28 ` Ian Lance Taylor
2011-01-12 8:45 ` Gidi Nave
0 siblings, 1 reply; 15+ messages in thread
From: Ian Lance Taylor @ 2011-01-12 6:28 UTC (permalink / raw)
To: Gidi Nave; +Cc: gcc
Gidi Nave <gidi.nave.1@gmail.com> writes:
> On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Gidi Nave <gidi.nave.1@gmail.com> writes:
>>
>>> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor <iant@google.com> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-12 6:28 ` Ian Lance Taylor
@ 2011-01-12 8:45 ` Gidi Nave
2011-01-12 13:50 ` Jeff Law
0 siblings, 1 reply; 15+ messages in thread
From: Gidi Nave @ 2011-01-12 8:45 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
On Wed, Jan 12, 2011 at 8:27 AM, Ian Lance Taylor <iant@google.com> wrote:
> Gidi Nave <gidi.nave.1@gmail.com> writes:
>
>> On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> Gidi Nave <gidi.nave.1@gmail.com> writes:
>>>
>>>> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor <iant@google.com> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-12 8:45 ` Gidi Nave
@ 2011-01-12 13:50 ` Jeff Law
2011-01-12 14:23 ` Gidi Nave
2011-01-12 16:11 ` Dave Korn
0 siblings, 2 replies; 15+ messages in thread
From: Jeff Law @ 2011-01-12 13:50 UTC (permalink / raw)
To: Gidi Nave; +Cc: Ian Lance Taylor, gcc
-----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-----
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-12 13:50 ` Jeff Law
@ 2011-01-12 14:23 ` Gidi Nave
2011-01-12 16:11 ` Dave Korn
1 sibling, 0 replies; 15+ messages in thread
From: Gidi Nave @ 2011-01-12 14:23 UTC (permalink / raw)
To: Jeff Law; +Cc: Ian Lance Taylor, gcc
On Wed, Jan 12, 2011 at 3:50 PM, Jeff Law <law@redhat.com> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-12 13:50 ` Jeff Law
2011-01-12 14:23 ` Gidi Nave
@ 2011-01-12 16:11 ` Dave Korn
2011-01-16 8:42 ` Gidi Nave
1 sibling, 1 reply; 15+ messages in thread
From: Dave Korn @ 2011-01-12 16:11 UTC (permalink / raw)
To: Jeff Law; +Cc: Gidi Nave, Ian Lance Taylor, gcc
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Plus Reload
2011-01-12 16:11 ` Dave Korn
@ 2011-01-16 8:42 ` Gidi Nave
0 siblings, 0 replies; 15+ messages in thread
From: Gidi Nave @ 2011-01-16 8:42 UTC (permalink / raw)
To: Dave Korn; +Cc: Jeff Law, Ian Lance Taylor, gcc
On Wed, Jan 12, 2011 at 6:36 PM, Dave Korn <dave.korn.cygwin@gmail.com> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Plus Reload
2011-01-11 14:59 ` Gidi Nave
2011-01-11 15:02 ` Gidi Nave
2011-01-11 15:34 ` Ian Lance Taylor
@ 2011-01-11 15:34 ` Jeff Law
2 siblings, 0 replies; 15+ messages in thread
From: Jeff Law @ 2011-01-11 15:34 UTC (permalink / raw)
To: Gidi Nave; +Cc: Ian Lance Taylor, gcc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/11/11 07:59, 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
You're probably going to need a secondary reload to deal with this case
d = r + -const
If you allocate another R register for the secondary reload, then you
could generate
R2 = -96
R2 = R1 + R2
D = R2
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNLHhlAAoJEBRtltQi2kC7vAQH/0zJq9h2oVDzY4PaSME88H9P
IPuy0RIfTZlmvMsZ2Uiik6bzacKgqgktMpc5b92JsF/XwgVOo98ehRq+x9I2+tMv
/o/pnpqN/qaBXPcF96LG7CMkxthkUJFg6Frif2ewpF5XC8wX2F7Zp/zTAYj8tPUd
KOEFKLSOL1jsKJGlqI1bmhp2LtwyqVVbXiSaJX0wNy40bn2v/FZz6PHV50///itr
1YHc4uS7nhODMNqY8JdyZW8lTOrg9CA73biQLlr63nqVFkwsSDCKoaq+kyZJjn9L
vBS3QWz36KMjVgNtY9pMXDLP2O93c++5tTpn9uXEgsCLO/e1O1cT3Z3ILaj7Dlc=
=DLmt
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 15+ messages in thread