Mixing C# and IL locals about inlineil.fody

[ltrzesniewski]

Hi Victor!

InlineIL doesn't let you access variables declared in C# that way primarily because that would produce very brittle code, as the compiler can decide to manage locals in unpredictable ways. For instance, a local can be present in Debug builds, but it could be entirely eliminated in Release builds if the compiler can use the stack instead. You couldn't also rely on the index of your local to be stable.

Because of this, InlineIL lets you treat locals defined by DeclareLocals as always starting at index 0, and then remaps the indices of locals in emitted IL instructions to the real index (it actually appends the locals you define to the ones that already exist, and Ldloc_1 in your example would load the value of bar). Changing this would be a major breaking change.

Note that in your example, baz is not an int32 local in IL, but is wrapped in a "DisplayClass" struct because of the IncrBaz method.

Still, you can access C# variables in InlineIL by using methods like IL.Push. In your example, if you replace Ldloc_1(); with IL.Push(baz);, you'll get baz on the stack. 😉

Similarly, IL.Push(ref baz); would push a ref to baz on the stack, and you could use IL.Pop(out baz); to assign the value on top of the stack to baz.

I'm not sure I understood you correctly though (I don't really understand the link between the example and your real use case), so let me know if something's still missing in that toolbox.

[ltrzesniewski]

Yeah, the for loop won't work, as you need to have a well-defined evaluation stack state for each basic block.

But I think you probably have a GC hole here since you're going through a void* local... I guess it depends on the way this is going to get JITted. 😕

I think I'll have to provide some kind of PopRef method or add something similar which would let you reassign a ref.

[buybackoff]

Good luck with that! 😄

Thanks! It's already faster than C on SciMark benchmark. But absolutely meaningless timing of the benchmark is 1095, and you could guess what my obsession is and what a round number is the goal 😂

I have implemented kind of JIT, or an optimization phase, that rewrites instructions from stack-based to virtual-registers based ones. Could eliminate more than 25% of all instructions. Without that the timing is at 1460. I should probably continue with this direction, and not IL rewrite.

Very fun experience overall.

[buybackoff]

With simple baz as int I understood how to do things, but what is baz was ref local, e.g. ref KeyValuePair<long,object> baz? I think there are not enough overloads to store a value to such baz, but maybe I missed something.

[buybackoff]

you could use IL.Pop(out baz); to assign the value on top of the stack to baz.

Probably this is what I've missed.

[ltrzesniewski]

I think with a ref local you can do anything you like on the target, but there's no method that would let you reassign the ref...

I initially tried to write IL.Pop as T Pop<T>() but I had to change it to void Pop<T>(out T value) since the other one didn't play very well with the compiler (it would emit code that did not lend itself to weaving very well). I guess I'd need to write a method like void Pop<T>(out ref T value) but that's not a valid signature 😢

I can see if I can add a ref T PopRef<T>() method, but I suppose if will prove difficult for the same reason as T Pop<T>() didn't work.

[buybackoff]

Do you think this creates a GC hole? DynValue is the same as KeyValuePair<long,object> from GC perspective.

This doesn't work as on the picture. But if I was sure it's safe from GC point of view, I will work out pointer arithmetics, maybe even without IL.

[buybackoff]

So this works:

But it doesn't with the loop:

The stack should be balanced

[buybackoff]

I was able to measure the impact of double inlining and it appears that the cost of for loop - additional local, int arithmetic, branch - is higher. Measured not exactly the same thing, but close, and will just leave two inlined methods. The main interest was to understand the impact. Sometimes very tiny obscure change improves (or kills) performance dramatically.

Thanks for your help! I really like how easy it is to use this lib 😄

[buybackoff]

I do not understand why the second picture from here doesn't work #23 (comment)

The stack should be balanced, we put two references on it in a loop, then pop outside the loop. The code is identical other than the loop...

If it worked, I would really like a method:

public ref T Ldlocal<T>(index or name) 

// usage

if(Ldlocal<DynValue>(0).IsNumber && Ldlocal<DynValue>(1).IsNumber)
    ...


// same as:

ref DynValue B = ref ...
ref DynValue C = ref ...
if(B.IsNumber && C.IsNumber)
   ...

So that there is no struct copying when accessing it's content for ref local.

[ltrzesniewski]

The evaluation stack doesn't work that way, its state needs to be statically defined at each instruction:

See ECMA-335, §I.12.3.2.1:

The evaluation stack is made up of slots that can hold any data type, including an unboxed
instance of a value type. The type state of the stack (the stack depth and types of each element on
the stack) at any given point in a program shall be identical for all possible control flow paths.
For example, a program that loops an unknown number of times and pushes a new element on
the stack at each iteration would be prohibited.

[buybackoff]

It's somewhat 🤯 to deal with dotnet value stack and locals while working on implementing value stack and locals. Those code sample are from Lua interpreter, trying to move values between the stack and variables in the most efficient branchless way 😀

[ltrzesniewski]

Haha yeah I can imagine 😅 Good luck with that! 😄