@dourouc05 : je ne dirais pas du tout assembleur, plutôt language bas niveau dans les instructions, mais de très haut niveau dans l'execution-flow.
notamment il travaille sur des graphes, après telle boucle, tel bloc d'instruction, puis tel appel récursif, le tout dans telle fonction, elle-même placée dans telle .dll, et le tout avec des problèmes de cache mémoire, de dépliement de boucles et d'appels récursifs, de simplification de tests redondants (notamment en C++ les type-check, genre dynamic-cast ou même appel virtuel), etc.
c'est notamment pour ça qu'il ne faut pas trop faire de "hacks" genre modifier un pointeur pour le remplacer par un int, etc. car sinon l'optimiseur ne comprend plus rien à l'execution-flow, voire se plante.
et pour conclure, c'est à cause de cet execution-flow que les bytecodes intermédiaires et les just-in-time compiler et les gestionnaires de mémoires sont intéressants, car en théorie ils sont capables de se servir du vrai execution-flow (qui dépend du contexte) pour optimiser certaines choses à l'exécution. (même si pour le moment ils sont loin d'être aussi élaborés : ils sont loin de "comprendre" le code)
1 |
0 |
Envoyé par MaximeCh
, dans les nouvelles normes C++ 17 19 22, ils veulent refaire le système d'include, un peu à la Java (dynamique versus statique). Mais parce que l'IR n'est pas normalisée, cela coince.
