I want to investigate a way for my other question (gcc: Strip unused functions) by building the latest gcc 6.3.0.
There are some options from https://gcc.gnu.org/install/configure.html and https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html that I would like to try, but don't understand what they meant.
Specifically, these are the flags I want to try:
--disable-libstdcxx-verbose: I rarely use exceptions so I am not very familiar with how it works. I have never seen the "verbose messages" it mentioned before.
--enable-linker-build-id and --enable-gnu-unique-object: Simply don't understand what the explanations are trying to say. What are the benefits exactly?
--enable-cxx-flags="-ffunction-sections -fstrict-aliasing -fno-exceptions": If I use -fno-exceptions in libstdc++, doesn't that means I get no exceptions if I use libstdc++? -ffunction-sections is used, but where to put -Wl,-gc-sections?
Although I always use --enable-lto, but with ld.bfd, it seems to be quite useless compared to the famous gold linker.
If you have more flags you think I should try, please let me know!
--disable-libstdcxx-verbose: I rarely use exceptions
so I am not very familiar with how it works. I have never seen the
"verbose messages" it mentioned before.
+1, you normally don't run into errors which trigger these friendly error messages you can avoid paying for them.
--enable-linker-build-id and --enable-gnu-unique-object:
Simply don't understand what the explanations are trying to say.
What are the benefits exactly?
There are none.
Unique objects is a badly designed feature that prevents shared libraries which contain references to globally used objects (usually vtables) from unloading on dlclose. AFAIR it's enabled by default (as it's needed to simulate C++ semantics in shared libs environment).
Build id is needed to support separate debuginfo.
--enable-cxx-flags="-ffunction-sections -fstrict-aliasing -fno-exceptions":
You won't benefit from -fstrict-aliasing as it's enabled at -O2 and higher by default.
-ffunction-sections is used, but where to put -Wl,-gc-sections?
To --enable-cxx-flags as well (note that it wants double-dash i.e. -Wl,--gc-sections).
Although I always use --enable-lto, but with ld.bfd,
it seems to be quite useless compared to the famous gold linker.
This flags simply enables LTO support in GCC (it's actually equivalent to adding lto to --enable-languages). It won't cause any difference unless you enable -flto in CXXFLAGS as well. Keep in mind that LTO will normally increase executable size (as compiler will have more opportunities for inlining).
If you have more flags you think I should try, please let me know!
Speaking of size reduction, I'd say -ffunction-sections is your best bet (be sure to verify that configure machinery passes all options correctly and libstdc++.a indeed has one section per function). You could also add -fdata-sections.
Related
GCC online doc - 3.10 Options That Control Optimization affirm that -fomit-frame-pointer gcc option can make debbuging impossible.
-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.
I understand why local variables are harder to locate and stack traces are much harder to reconstruct without a frame pointer to help out.
But, In what circumstances is it make debugging impossible?
It may be impossible in the sense that existing tools for these platforms (which are often provided by platform vendor, not GNU) expect frame pointer to be present for successful unwinding. One could theoretically modify them to be more intelligent but in practice this is not possible.
for University we need to implement our own va_start and va_arg (without using libraries) for variable argument lists.
This isn't really a problem, but gcc and clang are giving us a hard time.
They are optimizing the code so that the parameter are passed through registers and not on the stack, which makes our task impossible.
I already tried to use optimization -O0 but even then they seem to pass them in registers.
Is there a way to disable that feature?
best wishes
Leo
Edit:
We are using 64-bit machines only
Edit2:
I found this site:
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html
It describes macros which define if a parameter is passed on the stack or not.
Could I use these marcos somehow to tell gcc to pass all parameters on the stack?
I played around with them but sadly did not archive anything...
I'm trying to compile code on GCC that uses OpenACC to offload to an NVIDIA GPU but I haven't been able to find a similar compiler option to the one mentioned above. Is there a way to tell GCC to be more verbose on all operations related to offloading?
Unfortunately, GCC does not yet provide a user-friendly interface to such information (it's on the long TODO list...).
What you currently have to do is look at the dump files produced by -fdump-tree-[...] for the several compiler passes that are involved, and gather information that way, which requires understanding of GCC internals. Clearly not quite ideal :-/ -- and patches welcome probably is not the answer you've been hoping for.
Typically, for a compiler it is rather trivial to produce diagnostic messages for wrong syntax in source code ("expected [...] before/after/instead of [...]"), but what you're looking for is diagnostic messages for failed optimizations, and similar, which is much harder to produce in a form that's actually useful for a user, and so far we (that is, the GCC developers) have not been able to spend the required amount of time on this.
Considering that I'm building GCC from source + mpfr, gmp, mpc, libelf and binutils, is it a good idea to change the optimization flags like so
CFLAGS="-O3" CXXFLAGS="-O3" ./configure
while configuring GCC or any of the other software?
I have a c2duo.
EDIT: I'm worried about the fact that these flags could change the behaviour of those programs/libs.
There are two things which you can do:
If you're natively bootstrapping, you can do a full, and complete profile guided bootstrap. This will build the compiler and dependencies with a bootstrapped compiler providing the third round with the profile information it can use to optimize itself. After configure, do make profiledbootstrap. Note you can place the dependencies and stuff likke binutils and gdb inside the gcc source tree, and they should be built as well in the process.
If you don't want to go through a long profiled bootstrap process, set CFLAGS, CXXFLAGS, CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET, etc. at GCC configure time to:
-O2 -flto -march=core2
And set LDFLAGS and LDFLAGS_FOR_TARGET to
-flto
This will optimize the most and safest stuff.
Note that all this trouble will probably only result in a tiny speedup in the final executable.
Measure first, then optimize. In this case, I would first try
compiling gcc with the stock compiler and whatever the default
config settings are (step 0).
Once I was sure then compile completed cleanly, I would do
make distclean
or similar, and then measure the time to it took to compile with
that stock current compiler. (step 1).
Next, install the new gcc and measure the time the new gcc (and any
other tools), compiled with default configs, take to compile
themselves. (step 2)
Then, compile with whatever -O optmization levels or other
non-default settings you prefer. Once you are getting a
clean compile, do 'make distclean' and measure again how
long it takes the new default-settings gcc to compile itself
with non-default settings (step 3).
Now, you have a -O3 (or whatever) gcc that you can use to compile
itself, (step 4) measured in the same way as the other steps.
Finally, compare the timings (being sure you have started from the
same base state before each compile). The parts you really care
about are step 2 and step 4, but 1 and 3 may also be informative.
Note that this really measures only how fast gcc (or whatever
compiler) can compile itself, and if you write code that is
very different from that, your mileage may vary - but you can
use the same technique to measure and compare the speeds
of the various optimization levels when you compile whatever
code you compile frequently.
EDIT: I'm worried about the fact that this flags could change the behaviour of those programs/libs.
It should not, but sometimes does change/corrupt the behaviour.
If you want to be sure, stick with the well tested default settings.
Note that if other values lile -O1 or -O3 yielded dramatically better performance then those settings would have become standard and would have been tested by now.
I'm using g++ to compile and link a project consisting of about 15 c++ source files and 4 shared object files. Recently the linking time more than doubled, but I don't have the history of the makefile available to me. Is there any way to profile g++ to see what part of the linking is taking a long time?
Edit: After I noticed that the makefile was using -O3 optimizations all the time, I managed to halve the linking time just by removing that switch. Is there any good way I could have found this without trial and error?
Edit: I'm not actually interested in profiling how ld works. I'm interested in knowing how I can match increases in linking time to specific command line switches or object files.
Profiling g++ will prove futile, because g++ doesn't perform linking, the linker ld does.
Profiling ld will also likely not show you anything interesting, because linking time is most often dominated by disk I/O, and if your link isn't, you wouldn't know what to make of the profiling data, unless you understand ld internals.
If your link time is noticeable with only 15 files in the link, there is likely something wrong with your development system [1]; either it has a disk that is on its last legs and is constantly retrying, or you do not have enough memory to perform the link (linking is often RAM-intensive), and your system swaps like crazy.
Assuming you are on an ELF based system, you may also wish to try the new gold linker (part of binutils), which is often several times faster than the GNU ld.
[1] My typical links involve 1000s of objects, produce 200+MB executables, and finish in less than 60s.
If you have just hit your RAM limit, you'll be probably able to hear the disk working, and a system activity monitor will tell you that. But if linking is still CPU-bound (i.e. if CPU usage is still high), that's not the issue. And if linking is IO-bound, the most common culprit can be runtime info. Have a look at the executable size anyway.
To answer your problem in a different way: are you doing heavy template usage? For each usage of a template with a different type parameter, a new instance of the whole template is generated, so you get more work for the linker. To make that actually noticeable, though, you'd need to use some library really heavy on templates. A lot of ones from the Boost project qualifies - I got template-based code bloat when using Boost::Spirit with a complex grammar. And ~4000 lines of code compiled to 7,7M of executable - changing one line doubled the number of specializations required and the size of the final executable. Inlining helped a lot, though, leading to 1,9M of output.
Shared libraries might be causing other problems, you might want to look at documentation for -fvisibility=hidden, and it will improve your code anyway. From GCC manual for -fvisibility:
Using this feature can very substantially
improve linking and load times of shared object libraries, produce
more optimized code, provide near-perfect API export and prevent
symbol clashes. It is *strongly* recommended that you use this in
any shared objects you distribute.
In fact, the linker normally must support the possibility for the application or for other libraries to override symbols defined into the library, while typically this is not the intended usage. Note that using that is not for free however, it does require (trivial) code changes.
The link suggested by the docs is: http://gcc.gnu.org/wiki/Visibility
Both gcc and g++ support the -v verbose flag, which makes them output details of the current task.
If you're interested in really profiling the tools, you may want to check out Sysprof or OProfile.