Tous les compilateurs (ou presque) sont aujourd'hui capables de générer des instructions SSE2, il y a certains mainteneurs de logiciel qui font le choix ne pas les utiliser pour conserver une compatibilité matérielle plus large.

un même binaire peut dynamiquement utiliser ou pas les extensions. y'a pas forcement besoin de faire plusieurs binaires donc.

gcc sait faire cela directement (googler "GCC Function Multiversioning") ou le programmeur peut utiliser des libs externes qui différent suivant  ce que le cpu supporte.

Transcoder un fichier est plus lent avec des pointeurs plus larges? J'aimerais bien savoir pourquoi.
Je me demande dans quelle mesure le résultat est sensible à la moindre modification du programme ou un compilateur.

Ça peut effectivement beaucoup dépendre du compilateur, mais certains programmes sont pénalisés par la plus grande taille du code et des pointeurs en 64 bits, par rapport aux caches L1/L2.
Les CPU les plus anciens (P4 et Core 2 il me semble) n'ont pas toutes leur micro-optimisations sur le code 64 bits.

Bien sûr un test réalisé avec les options par défaut des compilateurs pourra être plus rapide en 64 bits grâce au SSE2 activé par défaut, et à l'optimisation pour des CPU plus récents (même si par exemple la version "i386" d'Ubuntu nécessite un CPU i686 avec CMOV (Pentium Pro/Pentium II, ...)).

Ça ne diminue pas les performances tout en augmentant la taille des binaires de faire cela ?

non, la taille augmente mais les perfs aussi si le cpu supporte les extensions. si le cpu ne supporte pas les extensions les perfs sont les memes.

La sélection du code a exécuter se fait une fois (au démarrage de l'application) et pas a chaque fois qu'on a besoin d'un code particulier d'ou la non perte de perfs si y'a pas des extensions dispo.

en gros: le programme démarre, teste le cpu pour savoir ce qu'il supporte et se spécialise lui-meme (se réécrit) pour que les meilleurs parties de code pour ce cpu soient utilisées (je simplifie un peu mais c'est l'idée).

Je connais encore 2 ou 3 Superdome encore en prod

de quelques Go à plusieurs centaines de Go.