Hello all,
I've filed bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
Regards,
Sergei
Andrew Haley wrote:
David Edelsohn wrote:
Andrew Haley writes:
Andrew> I suspect that the real reason for the change in save/restore
is because
Andrew> not using lmw/stmw is faster. That's just a
> Andrew Haley writes:
Andrew> Err, why not?
Because the fixed register means it no longer is a continuous
sequence of registers. And the PowerPC port does not break it up into two
sequences. And fixed registers in that range are not part of any standard
ABI.
David
David Edelsohn wrote:
Andrew Haley writes:
Andrew> I suspect that the real reason for the change in save/restore is because
Andrew> not using lmw/stmw is faster. That's just a guess though. gcc could
probably
Andrew> be fixed to use ldmw/stmw if -Os is used.
Andrew> Anyway, now we've found
> Andrew Haley writes:
Andrew> I suspect that the real reason for the change in save/restore is because
Andrew> not using lmw/stmw is faster. That's just a guess though. gcc could
probably
Andrew> be fixed to use ldmw/stmw if -Os is used.
Andrew> Anyway, now we've found something specific
Gabriel Paubert wrote:
On Thu, Jan 17, 2008 at 05:48:10PM +0300, Sergei Poselenov wrote:
Hello Andrew,
Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux
cross-compiler:
http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i
http://www.emcraft.com/codesize/gcc-4.2.2/interrup
On Thu, Jan 17, 2008 at 05:48:10PM +0300, Sergei Poselenov wrote:
> Hello Andrew,
>
> Andrew Haley wrote:
> >Sergei Poselenov writes:
> > > Hello Andrew,
> > >
> > > > Now, I sympathize that in your particular case you have a code size
> > > > regression. This happens: when we do optimization in
On Jan 17, 2008 3:48 PM, Sergei Poselenov <[EMAIL PROTECTED]> wrote:
> Hello Andrew,
>
> I agree. Actually, the CSiBE results are impressive: I've built the
> bzip2 library for powerpc and got similar results.
>
> I wonder why GCC maintainers are ignoring the -Os regression for
> most of their case
Hello Andrew,
Andrew Haley wrote:
Sergei Poselenov writes:
> Hello Andrew,
>
> > Now, I sympathize that in your particular case you have a code size
> > regression. This happens: when we do optimization in gcc, some code
> > bases will lose out. All that we can promise is that we try no
Hello Sergei,
On Thu, Jan 17, 2008 at 03:13:59PM +0300, Sergei Poselenov wrote:
> I don't know now, actually, this is what I'm asking. As for the
> target processor - as I stated in the initial message:
>
> ...
> Currently, it builds as following:
> ppc-linux-gcc -g -Os -fPIC -ffixed-r14
Hello Gabriel,
Gabriel Paubert wrote:
On Wed, Jan 16, 2008 at 04:55:19PM +0300, Sergei Poselenov wrote:
Hello,
I've just noted an error in my calculations: not 40%, but 10%
regression (used gdb to do the calculations and forgot to convert
inputs to float). Sorry.
But the problem still persist
On Wed, Jan 16, 2008 at 04:55:19PM +0300, Sergei Poselenov wrote:
> Hello,
>
> I've just noted an error in my calculations: not 40%, but 10%
> regression (used gdb to do the calculations and forgot to convert
> inputs to float). Sorry.
>
> But the problem still persists for me - I'm building an e
Sergei Poselenov writes:
> Hello Andrew,
>
> > Now, I sympathize that in your particular case you have a code size
> > regression. This happens: when we do optimization in gcc, some code
> > bases will lose out. All that we can promise is that we try not to
> > make it worse for most users
Hello Andrew,
Now, I sympathize that in your particular case you have a code size
regression. This happens: when we do optimization in gcc, some code
bases will lose out. All that we can promise is that we try not to
make it worse for most users.
What we can do is compare your code that has g
Sergei Poselenov writes:
> Hello,
>
> I've just noted an error in my calculations: not 40%, but 10%
> regression (used gdb to do the calculations and forgot to convert
> inputs to float). Sorry.
>
> But the problem still persists for me - I'm building an embedded
> firmware (U-Boot) and i
Hello,
I've just noted an error in my calculations: not 40%, but 10%
regression (used gdb to do the calculations and forgot to convert
inputs to float). Sorry.
But the problem still persists for me - I'm building an embedded
firmware (U-Boot) and it doesn't fit into the reserved space
anymore.
Sergei Poselenov writes:
>
> No, all results are for the GCC project. "Mainline" here means the
> current development version of GCC. For it, the sum of the test code
> size is 3503061, vs. 3542052 for the gcc_4_0_0 branch. But again,
> this performance is achieved by the significant regressi
Sergei Poselenov writes:
> Hello all,
>
> I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
> size have increased significantly (about 40%!), comparing with
> old 4.0.0 when using the -Os option. Same code, same compile-
> and configuration-time options. Binutils are differ
> (2
> LLVM? From what I know llvm-gcc is an alternative for gcc. Are any
> parts of LLVM used in current GCC? None of what I know.
Sorry, I confused my mailing lists and thought you had asked on
the LLVM mailing list. This explains why I didn't understand
your questions :)
Sorry about the noise,
Du
Hi Duncan,
Duncan Sands wrote:
Hi,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50),
Hi,
> I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
> size have increased significantly (about 40%!), comparing with
> old 4.0.0 when using the -Os option. Same code, same compile-
> and configuration-time options. Binutils are differ
> (2.16.1 vs 2.17.50), though.
what LLVM versi
Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50), though.
I've looked at th
21 matches
Mail list logo
