Is it generally dangerous to inline codes

[Xyncgas]

What are some examples of the danger of inline codes randomly?

I've noticed that in F# when I was working with NativePtr.stackalloc, I keep getting {"Common Language Runtime detected an invalid program."} exception in debug but not in release mode, isn't it interesting? If the function isn't using inline keyword then no problem, maybe I shouldn't inline function either in F# or in C# and let the compiler do it for me?

Is it better to inline manually

[Xyncgas]

Yes, inlining a function that has stack allocation inside can cause the "Common Language Runtime detected an invalid program" error in C# .NET.

Inlining is an optimization technique used by the .NET runtime to improve the performance of a program by replacing a function call with the actual code of the function. However, when a function that has stack allocation inside is inlined, it can cause issues with the stack frame layout and result in an invalid program.

Stack allocation involves allocating memory on the stack for local variables in a function. When the function returns, the stack frame is popped, and the memory is released. If the function is inlined, the compiler generates code that assumes the function's stack frame layout, and if it changes due to inlining, it can result in an invalid program.

Therefore, inlining a function that has stack allocation inside can cause issues with the stack frame layout, which can result in the "Common Language Runtime detected an invalid program" error in C# .NET. It is essential to be cautious while using inlining, and you should ensure that the function being inlined does not have stack allocation or uses it in a way that will not cause issues with the stack frame layout.

[Clockwork-Muse]

.... This sounds like a bug, if that's the case. Either inlining should be disabled in such cases, or the compiler should properly handle the stack rewrite.

[vzarytovskii]

.... This sounds like a bug, if that's the case. Either inlining should be disabled in such cases, or the compiler should properly handle the stack rewrite.

It's not, the only thing we do is literally inline the localloc IL call, nothing more. Using inline IL can (and probably will) result in an unverifiable code.

[tannergooding]

Worth noting that F#'s inline keyword is not the same as traditional .NET inlining (which is implicitly done or may be hinted to be done by the developer adding [MethodImpl(MethodImplOptions.AggressiveInlining)]

F#'s inline notably happens at F# compile time and is more akin to a macro splatting the contents into the callee rather than creating "proper" boundaries: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/functions/inline-functions -- This explanation is intended as a high level overview, it misses several subtleties that apply to the actual implementation and spec'd behavior

NativePtr.stackalloc is itself an inline function which uses the compiler's "inline IL" feature to call localloc: https://github.com/dotnet/fsharp/blob/main/src/FSharp.Core/nativeptr.fs#L69

This only works because of how F#'s inline is intended to work. If you're getting asserts from using it, then it's likely there is some other subtlety at play or potentially a bug/regression has crept in on the language side.

Could you provide a more complete example showing the code involved and the corresponding failure?

-- CC. @vzarytovskii

[vzarytovskii]

Yeah, OP will need to provide a more comprehensive example, since the only thing we do is literlly inline the localloc call:

let inline foobar () =
    let foo = NativeInterop.NativePtr.stackalloc<byte> 10
    0
    
[<EntryPoint>]
let main _ = foobar ()

.method public static 
    int32 main (
        string[] _arg1
    ) cil managed 
{
    .custom instance void [FSharp.Core]Microsoft.FSharp.Core.EntryPointAttribute::.ctor() = (
        01 00 00 00
    )
    // Method begins at RVA 0x206c
    // Code size 14 (0xe)
    .maxstack 4
    .locals init (
        [0] native int
    )

    IL_0000: ldc.i4.s 10
    IL_0002: sizeof [System.Runtime]System.Byte
    IL_0008: mul
    IL_0009: localloc
    IL_000b: stloc.0
    IL_000c: ldc.i4.0
    IL_000d: ret
} // end of method _::main

Since it's just an IL inline, we don't do any analysis what's getting called.

[teo-tsirpanis]

Duplicate of dotnet/fsharp#8083. Apparently the localloc instruction requires only the buffer's length to be present on the evaluation stack. The following F# program fails both in Debug and Release.

let foobar () =
    let foo = 1n + NativeInterop.NativePtr.toNativeInt (NativeInterop.NativePtr.stackalloc<byte> 10)
    0
    
[<EntryPoint>]
let main _ = foobar ()

[teo-tsirpanis]

The following C# program works correctly because Roslyn puts the stackalloced buffer in a temporary variable.

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

unsafe void Main()
{
	nint foo = 1 + (nint)Unsafe.AsPointer(ref MemoryMarshal.GetReference(stackalloc int[184]));
}

[vzarytovskii]

I see. Well, yeah, we don't have a special treatment for for stackalloc or any of inline IL. I've had an idea to do a better analysis when we ilgen, but never got to it

[Xyncgas]

For people who are curious

If I call this function in a static member function, it's ok, if I don't inline readBounded
Originaly I tried returning the span directly that's why I inlined the function imagining if it can let me return stackallocated bytes

Here's my writeBounded function if you are curious

and writeOptional

They are very useful for writing any primitives in F#