-Os

[Tomasz Pala]

On Sat, Apr 26, 2003 at 12:06:39 +0200, Robert Kurtys wrote:

> z przebiegu dyskusji wynika ze w zaleznosci od arch nalezy stosowac 
> rozne opcje optymalizacji

Raczej nie wynika, a jest takie podejrzenie - jak dotąd niepotwierdzone.

> do tego dochodzi specyfika danego programu : czy ma on byc 
> optymalizowany na szybkosc, wielkosc, cos innego
> dlatego IMHO w specu powinno byc %define __typ_pakietu
> gdzie typ pakietu to:kobyla;numeryczne;?????;specjalny

Gdzie mają być określone optymalizacje 'specjalnego' (optymalizowane na
'coś innego')?

> (wyglada na to ze tych typow optymalizacji nie bedzie tak duzo)
> a w samym rpmie bylyby zdefiniowane opcje optymalizacji per %arch - 
> %__typ_pakietu

Wszystko to będzie pięknie, dopóki nie okaże się, że na ia32 trzeba
optymalizować na rozmiar, a na sparcu na szybkość.

> zyski:
> -w specu dodajemy tylko 1 linijke (co ulatwia konserwacje)
> - dla nowych specow latwo wprowadzamy optymalizacje (kwalifikacja do 
> grupy)
> - w przypadku jakis zmian unikamy mass_commitow
> -no i czysto estetycznie calosc ladniej wyglada

Wady:
- to, co wspomniałem wyżej - jeśli w praniu moje obawy okażą się
  słuszne, albo za pół roku pojawi się nowy procesor, który będzie
  chodził inaczej, czy w gcc pojawią się optymalizacje dla Via C3, czy
  cokolwiek w ten deseń - będą problemy. Krótko mówiąc: zyskujemy
  niewiele ryzykując koniecznością przebudowywania wszystkiego. Nie
  podoba mi się nieprzyszłościowe podejście, wyżej już jest wątek o db3,
  db*, gdbm etc.
- gdzie w powyższym jest rozróżnienie na obecność -fomit-frame-pointer?
  Na kodzie c++ z -Os powoduje to _zwiększenie_ kodu wynikowego, zatem
  'kobyły' będziesz musiał dalej dzielić.

-- 
GoTaR <priv0.onet.pl->gotar>            USA sux
        ...Dżahilijja... znowu? Nadal...
PLD stuff at http://mops.uci.agh.edu.pl/~gotar/