Почему существуют локальные переменные в байт-коде IL на основе стека

В зависимости от ситуации, но особенно когда задействованы вызовы, где параметры должны быть переупорядочены, чтобы соответствовать вызову, чистого стека недостаточно, если в вашем распоряжении нет регистров или переменных. Если вы хотите сделать этот стек доступным только для стека, вам потребуются дополнительные возможности манипулирования стеком, такие как возможность обмена/перестановки двух верхних элементов стека.

В конце концов, несмотря на то, что в этом случае можно выразить все как чисто основанное на стеке, это может значительно усложнить код, раздуть его и затруднить оптимизацию (локальные переменные — идеальные кандидаты на роль кэшируется в регистрах).

Также помните, что в .NET вы можете передавать параметры по ссылке, как вы могли создать IL для вызова этого метода без локальной переменной?

bool TryGet(int key, out string value) {}

Этот ответ чисто умозрительный, но я подозреваю, что ответ состоит из 3 частей.

1: Преобразование кода, чтобы предпочесть Dup локальным переменным, очень нетривиально, даже если вы игнорируете побочные эффекты. Это значительно усложняет оптимизацию и потенциально увеличивает время ее выполнения.

2: Вы не можете игнорировать побочные эффекты. В примере, где все является просто литералом, очень легко понять, что значения находятся в стеке или в локальных переменных и, следовательно, полностью контролируются текущими инструкциями. Как только эти значения поступают из кучи, статической памяти или вызовов методов, вы больше не можете перетасовывать вещи, чтобы использовать Dup вместо локальных. Изменение порядка может изменить то, как все работает на самом деле, и вызвать непредвиденные последствия из-за побочных эффектов или внешнего доступа к общей памяти. Это означает, что обычно вы не можете выполнять эти оптимизации.

3: Предположение о том, что значения стека быстрее, чем локальные переменные, не является хорошим предположением — это может быть верно для конкретного преобразования IL-> машинного кода, что значения стека быстрее, но нет причин, по которым умный JIT не поместил бы расположение стека в память и локальную переменную в регистр. Задача JIT — узнать, что быстро, а что медленно для текущей машины, и задача JIT — решить проблему. По замыслу компилятор CIL не имеет ответа на вопрос, что быстрее — локальные или стековые; и поэтому измеримая разница между этими результатами заключается только в размере кода.

В совокупности 1 означает, что это сложно и имеет нетривиальную стоимость, 2 означает, что реальных случаев, когда это было бы полезно, немного, а 3 означает, что 1 и 2 в любом случае не имеют значения.

Даже если целью является минимизация размера CIL, что ЯВЛЯЕТСЯ измеримой целью компилятора CIL, причина № 2 описывает это как небольшое улучшение в небольшом количестве случаев. Принцип Парето не может сказать нам, что реализация такого рода оптимизации — ПЛОХАЯ идея, но он порекомендует, что есть, вероятно, ЛУЧШЕЕ использование времени разработчика.