some questions about GCC's options

some questions about GCC's options

[ohav chochmah]

hello all,
I have been playing with the command-line options recently, and I'l
appreciate answers, if someone has got time.

~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++
--enable-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-gnu-unique-object --enable-linker-build-id --with-ppl
--enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.7.0 20120505 (prerelease) (GCC)

~ $ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz

first, is momit-leaf-frame-pointer bad for debugging (in the way
fomit-frame-pointer can be)?, if not, why is it disabled by default
even when optimizing (as -Q --help=target | grep omit reveals)?
next, the manual mentions that fno-fat-lto-objects improves
compilation time over plain LTO, but requires the whole toolchain to
be aware of LTO and support plugins, which is why it's not (yet) the
default.  how can I know for certain if the toolchain I'm using meets
the criteria (seems to be the case)?
similarly, mtls-dialect=gnu2 is better then the default gnu, "but it
may add compile- and run-time requirements that cannot be satisfied on
all systems."  how can I test for them?
is it true that mfpmath=sse can result in poor code when using glibc?
(maybe I shouldn't ask that here...)
why is msse disabled by default even after march=native, while
msse[234], msse4.[12] and mssse3 are all enabled?
isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
default even when sse4.2 is enabled?

thanks in advance, and sorry for bothering...

Re: some questions about GCC's options

[Ian Lance Taylor]

ohav chochmah <philomath868@gmail.com> writes:

> first, is momit-leaf-frame-pointer bad for debugging (in the way
> fomit-frame-pointer can be)?

It's not as bad.  It may still trip up some debuggers.

> if not, why is it disabled by default
> even when optimizing (as -Q --help=target | grep omit reveals)?

When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
anyhow.  -fomit-frame-pointer essentially implies
-momit-leaf-frame-pointer.

> next, the manual mentions that fno-fat-lto-objects improves
> compilation time over plain LTO, but requires the whole toolchain to
> be aware of LTO and support plugins, which is why it's not (yet) the
> default.  how can I know for certain if the toolchain I'm using meets
> the criteria (seems to be the case)?

Use the most recent GNU binutils release.

> similarly, mtls-dialect=gnu2 is better then the default gnu, "but it
> may add compile- and run-time requirements that cannot be satisfied on
> all systems."  how can I test for them?

Build a program with it and see.  Basically your GNU binutils need to be
fairly new and your glibc needs to be 2.9 or later.

> is it true that mfpmath=sse can result in poor code when using glibc?
> (maybe I shouldn't ask that here...)

For x86_64 -mfpmath=sse is the default.

> why is msse disabled by default even after march=native, while
> msse[234], msse4.[12] and mssse3 are all enabled?

Not sure--what makes you think this is the case?

> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
> default even when sse4.2 is enabled?

It's not.  Don't be confused by the fact that -msse4.2 does not
automatically turn on -mcrc32.  Everything that is available when using
-mcrc32 is also available when using -msse4.2.

Ian

Re: some questions about GCC's options

[ohav chochmah]

On 6/1/12, Ian Lance Taylor <iant@google.com> wrote:
> ohav chochmah <philomath868@gmail.com> writes:
>
>> first, is momit-leaf-frame-pointer bad for debugging (in the way
>> fomit-frame-pointer can be)?
>
> It's not as bad.  It may still trip up some debuggers.
>
but not GDB?

>> if not, why is it disabled by default
>> even when optimizing (as -Q --help=target | grep omit reveals)?
>
> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
> anyhow.  -fomit-frame-pointer essentially implies
> -momit-leaf-frame-pointer.
>

I was sure that's the answer, but then is GCC lying to me?
~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit
  -fomit-frame-pointer        		[disabled]

>> next, the manual mentions that fno-fat-lto-objects improves
>> compilation time over plain LTO, but requires the whole toolchain to
>> be aware of LTO and support plugins, which is why it's not (yet) the
>> default.  how can I know for certain if the toolchain I'm using meets
>> the criteria (seems to be the case)?
>
> Use the most recent GNU binutils release.
>
good then, thanks.

>> similarly, mtls-dialect=gnu2 is better then the default gnu, "but it
>> may add compile- and run-time requirements that cannot be satisfied on
>> all systems."  how can I test for them?
>
> Build a program with it and see.  Basically your GNU binutils need to be
> fairly new and your glibc needs to be 2.9 or later.
>
good, thanks.
>> is it true that mfpmath=sse can result in poor code when using glibc?
>> (maybe I shouldn't ask that here...)
>
> For x86_64 -mfpmath=sse is the default.
>
here again:
~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep 'mfpmath='
  -mfpmath=                   		387

>> why is msse disabled by default even after march=native, while
>> msse[234], msse4.[12] and mssse3 are all enabled?
>
> Not sure--what makes you think this is the case?
>
sorry, 's/msse/mmmx/'.
~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep mmx
  -mmmx                       		[disabled]

~ $ sudo x86info -a -v | grep -i mmx
 mmx     	MMX support

>> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
>> default even when sse4.2 is enabled?
>
> It's not.  Don't be confused by the fact that -msse4.2 does not
> automatically turn on -mcrc32.  Everything that is available when using
> -mcrc32 is also available when using -msse4.2.
>
thanks.
> Ian
>
cheers.

Re: some questions about GCC's options

[xunxun]

于 2012/6/1 15:59, ohav chochmah 写道:
> On 6/1/12, Ian Lance Taylor<iant@google.com>  wrote:
>> ohav chochmah<philomath868@gmail.com>  writes:
>>
>>> first, is momit-leaf-frame-pointer bad for debugging (in the way
>>> fomit-frame-pointer can be)?
>> It's not as bad.  It may still trip up some debuggers.
>>
> but not GDB?
>
>>> if not, why is it disabled by default
>>> even when optimizing (as -Q --help=target | grep omit reveals)?
>> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
>> anyhow.  -fomit-frame-pointer essentially implies
>> -momit-leaf-frame-pointer.
>>
> I was sure that's the answer, but then is GCC lying to me?
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit
>    -fomit-frame-pointer        		[disabled]
x86 or x86_64?

I remembered -fomit-frame-pointer enabled only on x86_64 by default.
>
>>> next, the manual mentions that fno-fat-lto-objects improves
>>> compilation time over plain LTO, but requires the whole toolchain to
>>> be aware of LTO and support plugins, which is why it's not (yet) the
>>> default.  how can I know for certain if the toolchain I'm using meets
>>> the criteria (seems to be the case)?
>> Use the most recent GNU binutils release.
>>
> good then, thanks.
>
>>> similarly, mtls-dialect=gnu2 is better then the default gnu, "but it
>>> may add compile- and run-time requirements that cannot be satisfied on
>>> all systems."  how can I test for them?
>> Build a program with it and see.  Basically your GNU binutils need to be
>> fairly new and your glibc needs to be 2.9 or later.
>>
> good, thanks.
>>> is it true that mfpmath=sse can result in poor code when using glibc?
>>> (maybe I shouldn't ask that here...)
>> For x86_64 -mfpmath=sse is the default.
>>
> here again:
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep 'mfpmath='
>    -mfpmath=                   		387
>
>>> why is msse disabled by default even after march=native, while
>>> msse[234], msse4.[12] and mssse3 are all enabled?
>> Not sure--what makes you think this is the case?
>>
> sorry, 's/msse/mmmx/'.
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep mmx
>    -mmmx                       		[disabled]
>
> ~ $ sudo x86info -a -v | grep -i mmx
>   mmx     	MMX support
>
>>> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
>>> default even when sse4.2 is enabled?
>> It's not.  Don't be confused by the fact that -msse4.2 does not
>> automatically turn on -mcrc32.  Everything that is available when using
>> -mcrc32 is also available when using -msse4.2.
>>
> thanks.
>> Ian
>>
> cheers.


-- 
Best Regards,
xunxun

Re: some questions about GCC's options

[ohav chochmah]

On 6/1/12, xunxun <xunxun1982@gmail.com> wrote:
> 于 2012/6/1 15:59, ohav chochmah 写道:
>> On 6/1/12, Ian Lance Taylor<iant@google.com>  wrote:
>>> ohav chochmah<philomath868@gmail.com>  writes:
>>>
>>>> first, is momit-leaf-frame-pointer bad for debugging (in the way
>>>> fomit-frame-pointer can be)?
>>> It's not as bad.  It may still trip up some debuggers.
>>>
>> but not GDB?
>>
>>>> if not, why is it disabled by default
>>>> even when optimizing (as -Q --help=target | grep omit reveals)?
>>> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
>>> anyhow.  -fomit-frame-pointer essentially implies
>>> -momit-leaf-frame-pointer.
>>>
>> I was sure that's the answer, but then is GCC lying to me?
>> ~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit
>>    -fomit-frame-pointer        		[disabled]
> x86 or x86_64?
>
> I remembered -fomit-frame-pointer enabled only on x86_64 by default.

x86_64.
according to the manual, "Starting with GCC version 4.6, the default
setting (when not optimizing for size) for 32-bit Linux x86 and 32-bit
Darwin x86 targets has been changed to ‘-fomit-frame-pointer’.   The
default can be reverted to ‘-fno-omit-frame-pointer’ by configuring
GCC with the ‘--enable-frame-pointer’ configure option."  it does not
mention x86_64.
the bottom-line seems to be, that -Q --help=<class> is sometimes inaccurate.


> Best Regards,
> xunxun

all the best.

Re: some questions about GCC's options

[Ian Lance Taylor]

ohav chochmah <philomath868@gmail.com> writes:

> On 6/1/12, Ian Lance Taylor <iant@google.com> wrote:
>
>> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
>> anyhow.  -fomit-frame-pointer essentially implies
>> -momit-leaf-frame-pointer.
>>
>
> I was sure that's the answer, but then is GCC lying to me?
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit
>   -fomit-frame-pointer        		[disabled]

Basically, it's a bug.  When you use the --help=optimizers option, GCC
doesn't actually compile the file.  That means that it doesn't run
through the target specific code that causes -O2 to turn on
-fomit-frame-pointer.  And that means that the display is invalid.

Please file a bug report at http://gcc.gnu.org/bugzilla if there isn't
one open already.  Thanks.


>> For x86_64 -mfpmath=sse is the default.
>>
> here again:
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep 'mfpmath='
>   -mfpmath=                   		387

Same answer.  The -mfpmath setting is done in target specific code that
is not run when using --help.


>>> why is msse disabled by default even after march=native, while
>>> msse[234], msse4.[12] and mssse3 are all enabled?
>>
>> Not sure--what makes you think this is the case?
>>
> sorry, 's/msse/mmmx/'.
> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep mmx
>   -mmmx                       		[disabled]
>
> ~ $ sudo x86info -a -v | grep -i mmx
>  mmx     	MMX support
>
>>> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
>>> default even when sse4.2 is enabled?

Same answer.  Target specific code turns on -mmmx if -msse is on.

Ian

Re: some questions about GCC's options

[ohav chochmah]

On 6/1/12, Ian Lance Taylor <iant@google.com> wrote:
> ohav chochmah <philomath868@gmail.com> writes:
>
>> On 6/1/12, Ian Lance Taylor <iant@google.com> wrote:
>>
>>> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default
>>> anyhow.  -fomit-frame-pointer essentially implies
>>> -momit-leaf-frame-pointer.
>>>
>>
>> I was sure that's the answer, but then is GCC lying to me?
>> ~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit
>>   -fomit-frame-pointer        		[disabled]
>
> Basically, it's a bug.  When you use the --help=optimizers option, GCC
> doesn't actually compile the file.  That means that it doesn't run
> through the target specific code that causes -O2 to turn on
> -fomit-frame-pointer.  And that means that the display is invalid.
>
> Please file a bug report at http://gcc.gnu.org/bugzilla if there isn't
> one open already.  Thanks.
>
>
>>> For x86_64 -mfpmath=sse is the default.
>>>
>> here again:
>> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep 'mfpmath='
>>   -mfpmath=                   		387
>
> Same answer.  The -mfpmath setting is done in target specific code that
> is not run when using --help.
>
>
>>>> why is msse disabled by default even after march=native, while
>>>> msse[234], msse4.[12] and mssse3 are all enabled?
>>>
>>> Not sure--what makes you think this is the case?
>>>
>> sorry, 's/msse/mmmx/'.
>> ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep mmx
>>   -mmmx                       		[disabled]
>>
>> ~ $ sudo x86info -a -v | grep -i mmx
>>  mmx     	MMX support
>>
>>>> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
>>>> default even when sse4.2 is enabled?
>
> Same answer.  Target specific code turns on -mmmx if -msse is on.
>
> Ian
>

thanks, done at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53554 .
glad to contribute back something tiny...

cheers.