[MSIL] stack waarden eerst opslaan voor volgende instructie?

[MTWZZ]

In het project waar ik mee bezig ben wilden we in een DataGridView voor- en achtergrond kleuren van kolommen kunnen binden aan de datasource van de DataGridView. En dat is op zich geen probleem en is ook prima gelukt.
Omdat Reflection in dit opzicht een behoorlijke performance penalty is heb ik hiervoor een helper geschreven die met Reflection.Emit een method maakt die direct een waarde uit de datasource kan plukken ongeacht wat voor type dat is (DataSet, business objecten etc). Deze method zorgt er dus voor dat ik niet bij elke paint actie met reflection aan de gang moet om via PropertyInfo's en Invoke() calls waarden op te halen.

Goed voor zover de inleiding. Waar ik nu nog mee zit is het volgende. In de IL code zit er een paar keer het volgende:

code:

L_001f: unbox.any int32
L_0024: stloc.1 
L_0025: ldloc.1

Het lijkt mij vrij overbodig om eerst de waarde van de stack af te halen en in een local te zetten aangezien hij erna toch weer gebruikt wordt Ik heb het zo geklust omdat de C# compiler dit ook zo doet (beter goed gejat dan slecht bedacht).

Mijn vraag is dus als volgt; kun je die stloc/ldloc combinatie weglaten als je met de waarde die nu op de stack staat verder wil werken? Dus zo:

code:

L_001f: unbox.any int32
L_0024: ret

of

code:

L_001f: unbox.any int32
L_0024: ldarg.2
L_0025: ceq

Of is dit iets voor synchronisatie of iets anders dat ik over het hoofd zie?

[Zr40]

MTWZZ schreef op donderdag 22 maart 2007 @ 11:26:
Ik heb het zo geklust omdat de C# compiler dit ook zo doet.

Doet de C# compiler dit ook als je compiled in release mode?

[ Voor 7% gewijzigd door Zr40 op 22-03-2007 11:40 ]

[MTWZZ]

Jup. Voorbeeldje:

C#:

public class test {
    public static void Main(string[] args)
    {
        int i = 0;

        i = GetValue();
        if(i == 0) {
            Console.WriteLine("i == 0");
        } else {
            Console.WriteLine("i != 0");
        }
    }

    private static int GetValue() {
        return 0;
    }
}

Gecompiled met:

csc /t:exe /debug- /optimize+ /platform:x86 test.cs

en vervolgens:

ildasm /out=test.il test.exe

Geeft dan (alleen public static void Main()):

code:

.method public hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       33 (0x21)
    .maxstack  1
    .locals init (int32 V_0)
    IL_0000:  ldc.i4.0
    IL_0001:  stloc.0
    IL_0002:  call       int32 test::GetValue()
    IL_0007:  stloc.0
    IL_0008:  ldloc.0
    IL_0009:  brtrue.s   IL_0016

    IL_000b:  ldstr      "i == 0"
    IL_0010:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_0015:  ret

    IL_0016:  ldstr      "i != 0"
    IL_001b:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_0020:  ret
  } // end of method test::Main

Op regel 10 en 11 zie je dus dat ie nog steeds stloc/ldloc doet.

[MTWZZ]

* MTWZZ schopt het topic omhoog.

Ik heb inmiddels geprobeerd om het stloc/ldloc verhaaltje weg te laten en zoals ik al verwachtte werkt het wel.
Maar het blijft nog steeds vaag dat het toch elke keer wordt neergezet

[Zr40]

Ik vermoed dat het te maken heeft met debugger support. De JIT haalt dat waarschijnlijk zelf wel weg, maar als je hem onder een debugger start wil je natuurlijk wel zien dat de variabele i de juiste waarde geassigned krijgt.