Optymalizacja

W tak rozbudowanym projekcie, jak GCC trudno jest przewidywać wpływ poszczególnych wprowadzanych zmian na optymalność tworzonego kodu, dlatego GCC od początku towarzyszy dosyć sformalizowany proces testowania poszczególnych wersji (szczególnie rozwojowych). Porównywana jest zarówno wydajność aplikacji, jak i to, czy generowany kod jest poprawny (opracowywane są przykładowe procedury testowe, które np. sprawdzają wpływ optymalizacji na sposób wykonania kodu, czy m.in. wyniki zgadzają się z oczekiwaniami). Każdy może samodzielnie przetestować swoją wersję GCC, ale równocześnie dostępne są non stop serwery, które na bieżąco testują kolejne wersje rozwojowe GCC. Obecnie skonfigurowane są dwa systemy - jeden oparty na Intel PIII, uruchamiający test SPEC 95 i drugi, oparty na Athlon 1.2, wykonujący SPEC CPU2000.

SPEC 95 został opracowany przez Standard Performance Evaluation Corp., niekomercyjną organizację zrzeszającą firmy IT, producentów sprzętu, uniwersytety i inne jednostki badawcze. Opracowano 2 grupy testów - CINT95, który bada wydajność arytmetyki opartej na liczbach całkowitych, oraz CFP95, poświęcony analizie wydajności operacji zmiennoprzecinkowych.

SPEC 2000 jest kolejną generacją testów systemów komputerowych. Jednak, w odróżnieniu od SPEC 95, nie wykorzystuje on specjalnie opracowanych procedur, lecz fragmenty kodu rzeczywistych aplikacji. Analizowana jest więc zarówno wydajność procesora, pamięci, jak i kompilatora w realnych warunkach.

Analizy SPEC nie pozwalają wprawdzie dokładnie przetestować wszystkich opcji optymalizacyjnych GCC, ale są wystarczającym sposobem badania działania kolejnych wersji kompilatora i sprawdzania, czy pracują lepiej niż poprzednie. Testy są uruchamiane na tych samych konfiguracjach sprzętowych, dlatego kolejne wyniki są porównywalne.

Przyszłość GCC

Trwają prace nad rozbudową GCC. W roku 1999 zatwierdzono nowy standard C (ISO/IEC 9899), co wymusza zmiany w standardowej bibliotece kompilatora i wzbogacenie jej chociażby w dodatkowe funkcje math.h.

Jednocześnie by kompilator w pełni wykorzystywał możliwości architektury IA-64, konieczna jest taka modyfikacja algorytmów optymalizujących, by możliwe było wczytywanie danych z wyprzedzeniem oraz obsługa mechanizmów do "rozwijania" pętli, by więcej operacji wykonywanych było równolegle. Równocześnie planowane jest wprowadzenie nowej wersji optymalizatora, która będzie badać cały przebieg programu, a nie optymalizować tylko daną procedurę czy funkcję. Trwają również prace nad przygotowaniem zestawu testów pozwalających na analizę, które z opcji optymalizacyjnych tworzą najszybszy kod dla platformy Itanium. Prace nad kompilatorem dla środowiska 64-bitowego nie ograniczają się wyłącznie do platformy Intela, ale dotyczą również architektury x86-64T AMD. Opracowane są już: emulator procesora Hammer i ogólne zasady kompilacji. Dostępne są też testowe wersje GCC dla tego procesora (zmiany między IA-32 czy Athlonem a Hammerem są znacznie mniejsze niż pomiędzy architekturami IA-32 a IA-64).

Jest także opracowywana nowa wersja sprawdzania, czy indeks tablicy nie wykracza poza zakres, np. gdy zmienna indeksująca przyjmuje wartości ze znanego wcześniej zakresu, niecelowe jest sprawdzanie poprawności odwołania przy każdym dostępie do tablicy. Równocześnie twórcy GCC próbują zdefiniować tzw. wskaźniki z ograniczeniem. GCC generuje kod, który sprawdza, czy wskazywana komórka pamięci znajduje się w zadanym obszarze.

Wciąż trwają prace nad automatycznym upraszczaniem wyrażeń, jakie występują w kodzie C/C++. Wykorzystywana jest metoda Static Single Assignment (SSA), która w ramach projektu AST przekształca drzewo wykonania programu i wybiera optymalną ścieżkę kompilacji (co przekłada się na prędkość działania programu).

Seria kompilatorów GCC 3.1 ma także zawierać front-end dla innych niż dotychczas obsługiwane języki - w tym Modula-2 oraz Cobol. Najbardziej zaawansowane są prace nad językiem ADA.