Jakie są konkretne opcje, których potrzebowałbym do zbudowania w "trybie wydania" z pełną optymalizacją w GCC? Jeśli istnieje więcej niż jedna opcja, podaj listę wszystkich. Dzięki.Jak zbudować w trybie wydania z optymalizacją w GCC?
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Nie ma „jeden rozmiar dla wszystkich” - trzeba zrozumieć swoją aplikację, wymagań i flagi optymalizacji w celu określenia właściwego podzbioru dla binarny.
Albo odpowiedź chcesz: -O3
-O2 włączy wszystkie optymalizacje, które nie wymagają handlu przestrzeń \ prędkości off i wydaje się być jednym widzę stosowane najczęściej. -O3 zajmuje trochę miejsca dla transakcji szybkiego wyłączenia (jak funkcja wbudowana). -Os robi O2 plus robi inne rzeczy, aby zmniejszyć rozmiar kodu. To może sprawić, że rzeczy będą szybsze niż O3, poprawiając wykorzystanie pamięci podręcznej. (sprawdź, czy to działa.) Uwaga: istnieje wiele opcji, których nie dotyka żaden z przełączników O. Powodem, dla którego zostały pominięte, jest to, że często zależy to od rodzaju kodu, który piszesz, lub zależy od architektury.
Należy pamiętać, że gcc nie ma "trybu wydania" i "trybu debugowania" takiego jak MSVC. Cały kod to tylko kod. Obecność różnych opcji optymalizacji (-O2 i -Os są jedynymi, na które zazwyczaj trzeba się liczyć, chyba że robisz bardzo dokładne dostrojenie) modyfikuje wygenerowany kod, ale nie w taki sposób, aby zapobiec współdziałaniu z innymi zgodnymi z ABI kod. Generalnie potrzebujesz optymalizacji na rzeczy, które chcesz wydać.
Obecność opcji "-g" spowoduje, że rozszerzone symbole i informacje o kodzie źródłowym będą umieszczane w wygenerowanych plikach, co jest przydatne do debugowania, ale zwiększa rozmiar pliku (i ujawnia kod źródłowy), co jest czymś, czego często nie chcesz w "uwolnionych" plikach binarnych.
Ale one nie są wyłączne. Możesz mieć plik binarny skompilowany z informacjami o optymalizacji i debugowaniu lub bez nich.
Optymalizacja powinna być zazwyczaj wyłączona, jeśli zamierzasz debugować wygenerowany kod, w przeciwnym razie debugowanie okaże się doświadczeniem podobnym do filmu Davida Lyncha. – caf
To nie jest takie złe, przez cały czas patrzę na zrzuty stosów i wyniki valgrind z plików "release". Dopóki nie użyjesz -fomit-stack-pointer i zrozumiesz, że statyka może być wbudowana i niewidoczna, możesz przeczytać bardzo dużo kontekstu nawet z mocno zoptymalizowanego pliku binarnego. Jeśli twoje funkcje są krótkie, zazwyczaj możesz znaleźć wyrażenie, które rozbił się z domysły lub dwóch. –
Jednak w odróżnieniu od filmu Davida Lyncha, debuggery pozwalają widzowi przełączać się między różnymi poziomami rzeczywistości. Jeśli rozumiesz demontaż, to przechodzenie przez niego (z liniami źródłowymi przeplatanymi) zwykle ma sens nawet przy optymalizacji. Jeśli nie rozumiesz demontażu, wtedy się nauczymy. –
Oto część z Makefile, którego używam regularnie (w tym przykładzie próbuje zbudować program o nazwie foo).
Jeśli uruchomić go jak $ make BUILD=debug lub $ make debug następnie zostaną użyte Debug CFLAGS. Te wyłączają optymalizację (-O0) i zawierają symbole debugowania (-g).
Jeśli pominąć te flagi (uruchamiając $ make bez żadnych dodatkowych parametrów), będziesz budować wersję Release CFLAGS gdzie optymalizacja jest włączony (-O2), symbole debugowania pozbawiony (-s) i twierdzenia wyłączony (-DNDEBUG) .
Jak sugerowali inni, możesz eksperymentować z różnymi ustawieniami -O* zależnie od Twoich konkretnych potrzeb.
ifeq ($(BUILD),debug)
# "Debug" build - no optimization, and debugging symbols
CFLAGS += -O0 -g
else
# "Release" build - optimization, and no debug symbols
CFLAGS += -O2 -s -DNDEBUG
endif
all: foo
debug:
make "BUILD=debug"
foo: foo.o
# The rest of the makefile comes here...
Zrobiłem i nie mogłem znaleźć bezpośredniego wyjaśnienia. Mógłbym po prostu ssać przy szukaniu. – Polaris878
Poza tym punktem SO jest pokazywanie w wyszukiwarkach takich jak Google, więc lepiej jest mieć go tutaj tak czy inaczej. – Polaris878
Uczciwa rozmowa. Czy tego właśnie szukasz? A może potrzebujesz więcej kontekstu/informacji? – Josh