* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
@ 2010-04-26 13:39 ` jakub at gcc dot gnu dot org
2010-04-26 13:53 ` dje at gcc dot gnu dot org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-04-26 13:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jakub at gcc dot gnu dot org 2010-04-26 13:39 -------
config/rs6000/rs6000.md would need to add a add<mode>cc expander and handle
this, then if-conversion can do the rest of the work like it does on i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
2010-04-26 13:39 ` [Bug rtl-optimization/43892] " jakub at gcc dot gnu dot org
@ 2010-04-26 13:53 ` dje at gcc dot gnu dot org
2010-04-26 13:54 ` dje at gcc dot gnu dot org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dje at gcc dot gnu dot org @ 2010-04-26 13:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 -------
As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md
does not provide that named pattern yet.
--
dje at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet|i686-pc-linux-gnu |powerpc-*-*
Last reconfirmed|0000-00-00 00:00:00 |2010-04-26 13:52:59
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
2010-04-26 13:39 ` [Bug rtl-optimization/43892] " jakub at gcc dot gnu dot org
2010-04-26 13:53 ` dje at gcc dot gnu dot org
@ 2010-04-26 13:54 ` dje at gcc dot gnu dot org
2010-04-26 13:59 ` joakim dot tjernlund at transmode dot se
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dje at gcc dot gnu dot org @ 2010-04-26 13:54 UTC (permalink / raw)
To: gcc-bugs
--
dje at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (2 preceding siblings ...)
2010-04-26 13:54 ` dje at gcc dot gnu dot org
@ 2010-04-26 13:59 ` joakim dot tjernlund at transmode dot se
2010-04-26 14:43 ` rguenth at gcc dot gnu dot org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-04-26 13:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from joakim dot tjernlund at transmode dot se 2010-04-26 13:58 -------
Subject: Re: PowerPC suboptimal "add with carry" optimization
"dje at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote on 2010/04/26
15:53:01:
>
> ------- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 -------
> As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md
> does not provide that named pattern yet.
Will that also address the loop optimization? I don't think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (3 preceding siblings ...)
2010-04-26 13:59 ` joakim dot tjernlund at transmode dot se
@ 2010-04-26 14:43 ` rguenth at gcc dot gnu dot org
2010-04-26 15:19 ` joakim dot tjernlund at transmode dot se
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-04-26 14:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-26 14:43 -------
(In reply to comment #4)
> Subject: Re: PowerPC suboptimal "add with carry" optimization
>
> "dje at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote on 2010/04/26
> 15:53:01:
> >
> > ------- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 -------
> > As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md
> > does not provide that named pattern yet.
>
> Will that also address the loop optimization? I don't think so.
No.
Actually compilable testcase:
typedef unsigned int u32;
u32
add32carry(u32 sum, u32 x)
{
u32 z = sum + x;
if (sum + x < x)
z++;
return z;
}
u32
loop(u32 *buf, int len)
{
u32 sum = 0;
for(; len; --len)
sum = add32carry(sum, *++buf);
return sum;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (4 preceding siblings ...)
2010-04-26 14:43 ` rguenth at gcc dot gnu dot org
@ 2010-04-26 15:19 ` joakim dot tjernlund at transmode dot se
2010-05-20 12:14 ` [Bug regression/43892] " joakim dot tjernlund at transmode dot se
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-04-26 15:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from joakim dot tjernlund at transmode dot se 2010-04-26 15:18 -------
Subject: Re: PowerPC suboptimal "add with carry" optimization
"rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote on 2010/04/26
16:43:04:
> > Will that also address the loop optimization? I don't think so.
>
> No.
OK, would be nice if the loop case could be fixed too.
Just noticed this too:
add32carry:
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 0,0,3
mr 3,0
That could have been better even without "add with carry" optimization:
add32carry:
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 3,0,3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug regression/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (5 preceding siblings ...)
2010-04-26 15:19 ` joakim dot tjernlund at transmode dot se
@ 2010-05-20 12:14 ` joakim dot tjernlund at transmode dot se
2010-05-20 14:25 ` dje at gcc dot gnu dot org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-20 12:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from joakim dot tjernlund at transmode dot se 2010-05-20 12:13 -------
The below code doesn't generate any "add with carry" insn's for
either x86 nor powerpc:
u16
ipsum(u16 *buf, unsigned len, u16 sum)
{
int rest, carry ;
u32 acc_sum, *buf_u32, x;
acc_sum = sum;
len >>= 2;
buf_u32 = (u32 *) buf;
carry = 0;
for(buf_u32--; len; --len) {
x = *++buf_u32;
acc_sum += x;
acc_sum += carry;
carry = x > acc_sum ? 1 : 0;
}
acc_sum += carry;
/* Add back carry outs from top 16 bits to low 16 bits.
*/
acc_sum = (acc_sum >> 16) + (acc_sum & 0xffff); /* add high-16 to low-16
*/
acc_sum += (acc_sum >> 16); /* add carry */
return acc_sum;
}
--
joakim dot tjernlund at transmode dot se changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |normal
Component|rtl-optimization |regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug regression/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (6 preceding siblings ...)
2010-05-20 12:14 ` [Bug regression/43892] " joakim dot tjernlund at transmode dot se
@ 2010-05-20 14:25 ` dje at gcc dot gnu dot org
2010-05-20 14:48 ` joakim dot tjernlund at transmode dot se
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dje at gcc dot gnu dot org @ 2010-05-20 14:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from dje at gcc dot gnu dot org 2010-05-20 14:25 -------
Has anyone tested if generating an instruction sequence that uses the carry bit
actually improves performance on modern POWER processors? It reduces the
number of instructions, which is good when optimizing for size, but that may
not necessarily translate to performance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug regression/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (7 preceding siblings ...)
2010-05-20 14:25 ` dje at gcc dot gnu dot org
@ 2010-05-20 14:48 ` joakim dot tjernlund at transmode dot se
2010-05-21 0:28 ` dje at gcc dot gnu dot org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-20 14:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from joakim dot tjernlund at transmode dot se 2010-05-20 14:47 -------
(In reply to comment #8)
> Has anyone tested if generating an instruction sequence that uses the carry bit
> actually improves performance on modern POWER processors? It reduces the
> number of instructions, which is good when optimizing for size, but that may
> not necessarily translate to performance.
>
On my mpc8321 it is a big difference(don't have numbers handy). Why would
such a simply insn be a problem performance wise?
I know the kernel still uses the carry insn's for calculating the
Internet checksum.
I have also noticed that gcc 4.3.4 prefers to do post increment even
if I write *++buf, why is that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug regression/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (8 preceding siblings ...)
2010-05-20 14:48 ` joakim dot tjernlund at transmode dot se
@ 2010-05-21 0:28 ` dje at gcc dot gnu dot org
2010-05-21 6:23 ` joakim dot tjernlund at transmode dot se
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dje at gcc dot gnu dot org @ 2010-05-21 0:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from dje at gcc dot gnu dot org 2010-05-21 00:28 -------
> On my mpc8321 it is a big difference(don't have numbers handy). Why would
> such a simply insn be a problem performance wise?
> I know the kernel still uses the carry insn's for calculating the
> Internet checksum.
mpc8321 is a relatively simplistic pipeline. Processors like POWER4, 5, 6, 7
may not have the same characteristics. Even with carry bit register renaming,
it is an extra input/output to a dedicated resource, an extra register port.
XLC currently avoids carry completely for POWER5 and POWER6:
.add32carry:
add r5,r3,r4
cmpl 0,0,r5,r4
addi r3,r5,1
bclr BO_IF,CR0_LT
ori r3,r5,0x0000
blr
One cannot assume that fewer UISA instructions equates with fewer
microarchitecture operations and faster performance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug regression/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (9 preceding siblings ...)
2010-05-21 0:28 ` dje at gcc dot gnu dot org
@ 2010-05-21 6:23 ` joakim dot tjernlund at transmode dot se
2010-05-21 17:42 ` [Bug target/43892] " segher at gcc dot gnu dot org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-21 6:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from joakim dot tjernlund at transmode dot se 2010-05-21 06:23 -------
(In reply to comment #10)
> > On my mpc8321 it is a big difference(don't have numbers handy). Why would
> > such a simply insn be a problem performance wise?
> > I know the kernel still uses the carry insn's for calculating the
> > Internet checksum.
>
> mpc8321 is a relatively simplistic pipeline. Processors like POWER4, 5, 6, 7
> may not have the same characteristics. Even with carry bit register renaming,
> it is an extra input/output to a dedicated resource, an extra register port.
>
> XLC currently avoids carry completely for POWER5 and POWER6:
Avoids? I was under the impression the gcc doesn't try to be smart
yet so no ppc CPU gets to use the "add with carry" insn yet.
>
> .add32carry:
> add r5,r3,r4
> cmpl 0,0,r5,r4
> addi r3,r5,1
> bclr BO_IF,CR0_LT
> ori r3,r5,0x0000
> blr
>
> One cannot assume that fewer UISA instructions equates with fewer
> microarchitecture operations and faster performance.
If this is the case for something as simple as add with carry, one really
needs a simple way to tell gcc what ppc class CPU one wants to use.
Otherwise only the fastest CPUs gets optimal code and the rest, that
really needs fast code, gets punished.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (10 preceding siblings ...)
2010-05-21 6:23 ` joakim dot tjernlund at transmode dot se
@ 2010-05-21 17:42 ` segher at gcc dot gnu dot org
2010-05-25 21:42 ` joakim dot tjernlund at transmode dot se
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: segher at gcc dot gnu dot org @ 2010-05-21 17:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from segher at gcc dot gnu dot org 2010-05-21 17:42 -------
(In reply to comment #11)
> If this is the case for something as simple as add with carry, one really
> needs a simple way to tell gcc what ppc class CPU one wants to use.
Please see -mcpu= .
--
segher at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu dot
| |org
AssignedTo|unassigned at gcc dot gnu |segher at gcc dot gnu dot
|dot org |org
Severity|normal |enhancement
Status|NEW |ASSIGNED
Component|regression |target
Last reconfirmed|2010-04-26 13:52:59 |2010-05-21 17:42:28
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (11 preceding siblings ...)
2010-05-21 17:42 ` [Bug target/43892] " segher at gcc dot gnu dot org
@ 2010-05-25 21:42 ` joakim dot tjernlund at transmode dot se
2010-05-26 16:46 ` segher at kernel dot crashing dot org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-25 21:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from joakim dot tjernlund at transmode dot se 2010-05-25 21:42 -------
(In reply to comment #12)
> (In reply to comment #11)
> > If this is the case for something as simple as add with carry, one really
> > needs a simple way to tell gcc what ppc class CPU one wants to use.
>
> Please see -mcpu= .
>
Almost forgot, but how do I specify that at gcc build/configure ?
Also, I haven't seen any progress on this issue even though it sounded that the
initial fix was easy(add<mode>cc expander)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (12 preceding siblings ...)
2010-05-25 21:42 ` joakim dot tjernlund at transmode dot se
@ 2010-05-26 16:46 ` segher at kernel dot crashing dot org
2010-05-26 20:47 ` joakim dot tjernlund at transmode dot se
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: segher at kernel dot crashing dot org @ 2010-05-26 16:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from segher at kernel dot crashing dot org 2010-05-26 16:46 -------
(In reply to comment #13)
> > Please see -mcpu= .
>
> Almost forgot, but how do I specify that at gcc build/configure ?
You can configure with --with-cpu= to set a default for -mcpu= .
> Also, I haven't seen any progress on this issue
You have no patience, now do you?
> even though it sounded that the
> initial fix was easy(add<mode>cc expander)
The fix will be a few thousand lines of patch. Literally.
In order to fix this problem (and a whole host of way more important
missed optimisation opportunities) we need to expose the CA bit to
the compiler as an actual register. Currently, whenever GCC uses the
carry bit it does so by having the consumer and producer in a canned
asm sequence; this is suboptimal for many reasons.
Fixing it properly will take a while.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (13 preceding siblings ...)
2010-05-26 16:46 ` segher at kernel dot crashing dot org
@ 2010-05-26 20:47 ` joakim dot tjernlund at transmode dot se
2010-05-27 1:37 ` dje at gcc dot gnu dot org
2010-05-27 7:33 ` joakim dot tjernlund at transmode dot se
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-26 20:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from joakim dot tjernlund at transmode dot se 2010-05-26 20:47 -------
(In reply to comment #14)
> (In reply to comment #13)
> > > Please see -mcpu= .
> >
> > Almost forgot, but how do I specify that at gcc build/configure ?
>
> You can configure with --with-cpu= to set a default for -mcpu= .
Thanks.
>
> > Also, I haven't seen any progress on this issue
>
> You have no patience, now do you?
Sure I do. It is just that its been almost a month and from the
description it sounded like an easy fix:
"config/rs6000/rs6000.md would need to add a add<mode>cc expander"
>
> > even though it sounded that the
> > initial fix was easy(add<mode>cc expander)
>
> The fix will be a few thousand lines of patch. Literally.
Oops, just to add a cc expander?
>
> In order to fix this problem (and a whole host of way more important
> missed optimisation opportunities) we need to expose the CA bit to
> the compiler as an actual register. Currently, whenever GCC uses the
> carry bit it does so by having the consumer and producer in a canned
> asm sequence; this is suboptimal for many reasons.
This looks like you are aiming for the ultimate impl. so
you can address other cases too. I can understand that takes
some time :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (14 preceding siblings ...)
2010-05-26 20:47 ` joakim dot tjernlund at transmode dot se
@ 2010-05-27 1:37 ` dje at gcc dot gnu dot org
2010-05-27 7:33 ` joakim dot tjernlund at transmode dot se
16 siblings, 0 replies; 18+ messages in thread
From: dje at gcc dot gnu dot org @ 2010-05-27 1:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from dje at gcc dot gnu dot org 2010-05-27 01:37 -------
>> You have no patience, now do you?
> Sure I do. It is just that its been almost a month and from the
> description it sounded like an easy fix:
> "config/rs6000/rs6000.md would need to add a add<mode>cc expander"
No you do not have any patience; in fact, your comments are rather obnoxious,
such as: "its been almost a month". If you do not know what you are talking
about, stop talking. No, it is not an easy fix. The high-level concept and
description is simple, the implementation is extremely complex and tedious.
>> even though it sounded that the
>> initial fix was easy(add<mode>cc expander)
>
>> The fix will be a few thousand lines of patch. Literally.
> Oops, just to add a cc expander?
Yes. Again, if you do not know the complexity of what you are requesting, get
more information instead of acting annoyed that people are not jumping to solve
your problem.
It is not "just adding" a cc expander. Do you even know what that means or
what it involves? For the expander to be effective, the PowerPC port of GCC
needs to be taught to track the carry bit, which it currently does not. *ALL*
patterns that produce instructions affecting the carry bit must be updated.
One cannot add the pattern in isolation.
If you do not understand the implications of your request, then *ask* why it is
more complicated than you assumed. There is no "simple" fix. The only fix is
the ultimate fix: completely propagating the carry bit throughout the PowerPC
port.
You apparently have not read the documentation to understand the -mcpu= option
or the --with-cpu= configure option. You are making a lot of incorrect
assumption and assertions, apparently without making any effort to gain some
knowledge before you start writing. That really does not encourage anyone to
help you, especially when it requires a lot of work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/43892] PowerPC suboptimal "add with carry" optimization
2010-04-26 13:33 [Bug rtl-optimization/43892] New: PowerPC suboptimal "add with carry" optimization gcc-bugzilla at gcc dot gnu dot org
` (15 preceding siblings ...)
2010-05-27 1:37 ` dje at gcc dot gnu dot org
@ 2010-05-27 7:33 ` joakim dot tjernlund at transmode dot se
16 siblings, 0 replies; 18+ messages in thread
From: joakim dot tjernlund at transmode dot se @ 2010-05-27 7:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from joakim dot tjernlund at transmode dot se 2010-05-27 07:33 -------
(In reply to comment #16)
> >> You have no patience, now do you?
>
> > Sure I do. It is just that its been almost a month and from the
> > description it sounded like an easy fix:
> > "config/rs6000/rs6000.md would need to add a add<mode>cc expander"
>
> No you do not have any patience; in fact, your comments are rather obnoxious,
> such as: "its been almost a month". If you do not know what you are talking
> about, stop talking. No, it is not an easy fix. The high-level concept and
> description is simple, the implementation is extremely complex and tedious.
Oops, sorry if I sounded obnoxious. Of course I don't know what I am talking
about. I am not a gcc dev. and gcc is a complex piece of SW but I don't
think I should just shut up either. Now that you have made it clear what is
involved I will stop pestering you, I was hoping you would have a small
patch for me to test but I see now that it won't happen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
^ permalink raw reply [flat|nested] 18+ messages in thread