Re: September 2015 GNU Toolchain Update
Hi Alan, On Fri, Sep 25, 2015 at 01:33:34PM +0100, Nick Clifton wrote: * The new PowerPC64 specific linker command line option --no-save-restore-funcs tells the linker not to provide the out-of-line register save and restore functions used by -Os compiled code. The default is to provide any such referenced function for a normal final link, but not do so for a relocatable link. Actually, --save-restore-funcs and --no-save-restore-funcs have been around since 2014-02. The recent new PowerPC64 option is --tls-get-addr-optimize, a complement to --no-tls-get-addr-optimize. Doh! Sorry about that. Cheers Nick
[optimization missed] Why do x86 gcc need extension here?
Simple test:
---
struct U {
unsigned s: 1;
};
struct V {
unsigned short o: 7;
unsigned short u: 1;
};
extern struct U t[];
extern struct V d[];
unsigned
foo ()
{
struct V descr = d[0];
unsigned osize = descr.o;
if ( descr.u )
{
struct U udata = t[osize];
if (udata.s) osize++;
}
return osize;
}
---
Compiled with specified gcc:
>gcc -v
Using built-in specs.
COLLECT_GCC=/tools/local/gcc-5.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/tools/local/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure
--prefix=/tools/local/gcc-5.2.0 --program-suffix=-5.2.0
--with-as=/tools/local/binutils-2.24/bin/as
--with-ld=/tools/local/binutils-2.24/bin/ld
Thread model: posix
gcc version 5.2.0 (GCC)
---
with options: -02 -S
---
Yields assembler:
---
foo:
movzbl d(%rip), %eax
andl$127, %eax
cmpb$0, d(%rip)
movzbl %al, %eax // <- why this is here?
jns .L2
movl%eax, %edx
movlt(,%rdx,4), %edx
andl$1, %edx
cmpb$1, %dl
sbbl$-1, %eax
.L2:
rep ret
---
I can not understand why second movzbl is here? andl already bitwise
and register eax with 127, why do someone need to zero-extend it one
more time?
May be some optimization missed here and it makes sense to file a
ticket in bugzilla? Or maybe I do not understand something?
Problem go away if I change unsigned short to unsigned int in bitfield
type inside structure V.
Re: [optimization missed] Why do x86 gcc need extension here?
On 09/28/2015 09:09 AM, Konstantin Vladimirov wrote:
Simple test:
---
struct U {
unsigned s: 1;
};
struct V {
unsigned short o: 7;
unsigned short u: 1;
};
extern struct U t[];
extern struct V d[];
unsigned
foo ()
{
struct V descr = d[0];
unsigned osize = descr.o;
if ( descr.u )
{
struct U udata = t[osize];
if (udata.s) osize++;
}
return osize;
}
---
Compiled with specified gcc:
gcc -v
Using built-in specs.
COLLECT_GCC=/tools/local/gcc-5.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/tools/local/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure
--prefix=/tools/local/gcc-5.2.0 --program-suffix=-5.2.0
--with-as=/tools/local/binutils-2.24/bin/as
--with-ld=/tools/local/binutils-2.24/bin/ld
Thread model: posix
gcc version 5.2.0 (GCC)
---
with options: -02 -S
---
Yields assembler:
---
foo:
movzbl d(%rip), %eax
andl$127, %eax
cmpb$0, d(%rip)
movzbl %al, %eax // <- why this is here?
jns .L2
movl%eax, %edx
movlt(,%rdx,4), %edx
andl$1, %edx
cmpb$1, %dl
sbbl$-1, %eax
.L2:
rep ret
---
I can not understand why second movzbl is here? andl already bitwise
and register eax with 127, why do someone need to zero-extend it one
more time?
May be some optimization missed here and it makes sense to file a
ticket in bugzilla? Or maybe I do not understand something?
Problem go away if I change unsigned short to unsigned int in bitfield
type inside structure V.
Please file a bug report. The x86 backend is trying to avoid redundant
prefixes via a splitter which is creating the redundant extension fairly
late in the optimizer pipeline. Redundant extension removal doesn't
remove it.
jeff
different results from objdump for Ubuntu and Windows
I built a gcc toolchain on Ubuntu and cygwin on Windows. The results from objdump are different. Is this normal? Is there a way to make them the same? Thanks, Helen
Re: different results from objdump for Ubuntu and Windows
On Mon, Sep 28, 2015 at 2:23 PM, Helen Tang wrote: > I built a gcc toolchain on Ubuntu and cygwin on Windows. The results > from objdump are different. Is this normal? Is there a way to make > them the same? It shouldn't happen on the same input file. If it does, please open a bug report. -- H.J.
