Проблемы декомпиляции при плохой оптимизации

[Leo B.]

Рассмотрим тривиальную программу на Фортране:

      program main
      common/D0/D01,D02,D03,D04,D05,D06,D07,D08,D09,D010
      D08 = D09
      D03 = D05
      D06 = D03

      ...  сколько- то там случайных присваиваний туда-сюда

      end

и скомпилируем её Фортраном-ГДР. Получим, как и ожидается  от оптимизирующего компилятора,  нечто вроде
         *D0*:,LС,10

...

         1,VТМ,*D0*
          1,ХТА,8
          1,АТХ,7
          1,ХТА,4
          1,АТХ,2
          1,ХТА,2
          1,АТХ,5
...

(peephole оптимизацию считывания после записи в данном случае не нажили, ну да ладно; хотя в принципе они мне попадались)

А теперь сделаем тривиальное изменение в программе:
      program main
      common/D0/D(10)
      D(8) = D(9)
      D(3) = D(5)
      D(6) = D(3)

...
Внезапно, получим
         ,UТС,*D0*+8
          ,ХТА,
          ,UТС,*D0*+7
          ,АТХ,
          ,UТС,*D0*+4
          ,ХТА,
          ,UТС,*D0*+2
          ,АТХ,
          ,UТС,*D0*+2
          ,ХТА,
          ,UТС,*D0*+5
          ,АТХ,
...
И так для первых 10 операторов присваивания в программе. Потом он спохватывается, устанавливает базу на регистр 1, и становится всё как раньше.

Когда в программе используется несколько common-блоков, то подобрать на основании сочетания UTC  и сдвигов по регистрам при обращении к  разным переменным этих блоков, где в блоках были отдельные переменные, а где массивы, чтобы добиться полного совпадения результата компиляции с оригиналом, оказывается практически невозможно.

Для справки: Фортран-Дубна всё всегда делает с помощью UTC; Форекс  в обоих случаях сразу пользуется базовым регистром,  и peephole оптимизация  тоже в принципе имеется, но в приведенном фрагменте не срабатывает, и для более длинных вариантов программы  эти оптимизации оказываются почему-то разные.

Leo