1. Los dos patrones que describí son las cosas fáciles que el JIT realmente hace bien (a excepción de las estructuras no primitivas). En forma SSA, la propagación constante y la eliminación de valores muertos es muy fácil.
2. No, tienes que probar lo que puede hacer el JIT. Mire la literatura del compilador para ver qué optimizaciones estándar esperar. Luego, prueba para ellos. Los dos JIT que tenemos ahora optimizan muy poco y, a veces, no hacen bien las cosas más básicas. Por ejemplo, MyStruct s; sx = 1; sx = 1; no está optimizado por RyuJIT. s = s; tampoco lo es sx + sx carga x dos veces desde la memoria. Espera poco.
3. Debe comprender a qué se asignan las operaciones básicas del código de máquina. Esto no es demasiado complicado. Pruebe algunas cosas y mire la lista de desmontaje. Rápidamente obtendrá una idea de cómo se verá la salida.

Las conversiones redundantes y la carga/almacenamiento como ese son un efecto secundario bastante inevitable de un analizador recursivo decente. Técnicamente, puedes deshacerte de ellos con un optimizador de mirilla. Pero no hay de qué preocuparse, los compiladores de C# y VB.NET también los generan.

Los nervios de .NET/Mono existentes son muy buenos para optimizarlos. Se enfocan en optimizar el código que realmente importa para la velocidad de ejecución, el código máquina. Con la gran ventaja de que cualquiera que escriba un compilador que genere IL automáticamente se beneficia de estas optimizaciones sin tener que hacer nada especial.

Las optimizaciones de jitter están cubiertas en esta publicación .