Inline literal delegates passed to functions

[DemiMarie]

This is a feature request to inline literal delegates passed to functions, so that the IL generated by

Array.map (fun x -> x) some_array

or its C# equivalent has no indirect dispatch.

category:cq
theme:inlining
skill-level:expert
cost:large

[pgavlin]

cc @AndyAyersMS @dotnet/jit-contrib

[russellhadley]

@pgavlin, Andy is out for a while. @kyulee1 is inliner backup.

[AndyAyersMS]

See my long and rambling series of notes over in #4584 for some context. There is quite a bit of up front work needed to support this, even in very simple / obvious cases.

[ldematte]

Hi there, I arrived here from #34634 through #4584. Someone rightly pointed out that discussion/information about inlining delegates is more at home here, even if the two issues are deeply related, so here I am. I though it might be useful to add my scenario both for you guys (to have more use cases if you are going to implement the feature) and for me, to understand if my scenario could benefit from this feature, if it is something even more complicated, and/or if I could/should do something to make the code "easier" on the JITer.

I code mainly in C#, but (like Mike_E in the other thread) my team and I found that we are using a kind of "functional" programming style, rich in delegates.
In most places we do not care too much about inlining, we do not need that level of optimization; in some cases however this optimization is something we would really like to have.
I am working on the streaming core of our applications. You can think of it as a pipeline, were raw data received from a stream need to be transformed and forwarded for further processing (accumulation, further streaming, computation).
Data from the input are of many different types (bitflag, int, short, float, etc.) and each can be transformed through different operations.

We have experimented various approaches on how to build the pipeline in the most efficient way; in some parts we use dynamically compiled expressions (Expression.Compile), but for the most it is a mix of 2 delegate-heavy techniques.

The first is, we use a lot of continuations, were we pass to a operation what we want to do next:

void Operation(T input, Action<T> optionA, Action<T> optionB, Action<Exception> failure) { }

We even have some cases where this is nested, like:

void OptionalRead(Action<int, Action<byte[], int, int>> callback);

OptionalRead((flag, reader) => { 
    if (some condition) { 
        reader(buffer, startPos, len);
    }
}

The other case is in building the operations themselves. Since the choices depend on type and input, are multiple, and they are expanding over the releases but are fixed for a well defined period, we want to avoid to end up with code that is a nightmare of "if", based mostly on conditions that we know are not going to change.

For example
void process() {
if (type == TypeCode.Int32)
if (bitOperation != 0) // <-- bitOperation never changes for this execution
if (bitMask != 0) // same...

We could have composed operations using interfaces and classes with an Invoke method, but this looks a lot like a delegate, so we build a delegate

Func<T, T> BuildBitOperation() {
     if (type == TypeCode.Int32)              
         if (bitOperation == 0) 
             return x => x;
    // all the other cases         
}

which is stored and later used with the other ones.
I know, the examples could seem silly and maybe you may say that building delegates this way is over-complicated, but for our purposes it is working well... the only drawback being that we have lots of callvirt Invoke in IL. And as you can see in the example, there are often paths where the operation ends up being identity. At least for those "fast paths" inlining would be very welcome.

I have read @AndyAyersMS comments on the other issue, and it seems that full inlining is a long way. Also, if I got it correctly, this case (returning a simple delegate with no local captures) would not even benefit from it as it is not invoked immediately, but is it returned and invoked elsewhere.