Looking for Suggestions on Using Slang (Source Code or IR) as Backend for Dotnet CIL Frontend

[Hong-Xiang]

Hello Slang Team,

I'd like to begin by expressing my sincere gratitude for the Slang project, which has been of significant help and brings new possibility to my project - a compiler(transpiler) prototype that transpiles C# to shader languages, or more specifically from dotnet CIL to WGSL. My initial approach was an ad-hoc emitter for WGSL, but I recently found Slang. Its rich language features, reflection capabilities, webgpu/wasm support (and hopefully future CPU SIMD target) are exactly my original motivations for developing such an dotnet CIL to (graphics) shader transpiler.
And fortunately, it provides COM-like API, which could significantly simplify .NET integration.

After a recent refactor, I have a minimal proof-of-concept that emits Slang source code and uses slangc CLI to generate WGSL. it works for some simple "shader toy"-style programs.

While my knowledge of Slang's internals is still very limited, I'm encountering some challenges that lead me to consider that emitting Slang's IR directly might be a more robust/longer term easier approach than generating Slang source code. I would be very grateful for your thoughts and suggestions on this idea.

Here are my primary motivations and questions:

Question 1: Simpler IR-to-IR Transformation

My compiler's frontend is dotnet CIL, which is a linear, stack-based IR. I perform custom analysis to transform it into an SSA-based IR, using block arguments instead of phi-nodes, like Slang IR.
I've implemented a simple version of recover structural control flow algorithm which is somehow related to Relooper based on this papar, to recover structural control flow from control flow graph. The structural control flow is in the sense similar to WASM, thus only allowing jump to proper nest regions, not arbitrary jump.
This is still not same meaning of structured control flow in Slang, but with some post dominance analysis its already close.

However, to emit slang source code from my "structural control flow IR", there is still a recovery process, which involves identifying continue and break statements from block branches, adds some seemly unnecessary complexity. Thus currently my pipeline is like from SSA IR -> Slang source code -> Slang SSA IR, which seems source code recovery is redundant and brings more challenges.

Question: Would emitting Slang IR directly from my SSA-form IR be a more direct and robust approach, bypassing the need for Slang source code recovery?

Before emitting Slang source code, I also tried to emit SPIRV, but I found that although SPIRV is a SSA like linear IR with detailed specification, which seems would be easier to emit from my linear SSA IR, it is actually harder to emit at least for simple shaders as there is much more details to handle, e.g. finding and mapping to right instruction set (with GLSL extension etc), properly handing memory space etc.
Since slang itself has higher level abstraction, I'm assuming emit Slang IR would be easier than SPIRV, is that correct? One concern is that Slang source code is easier to understand and with more documentation, I'm not sure if emitting Slang IR would be suitable to be used as a backend.

Question 2: Handling Control Flow With Reused Blocks

Certain code patterns, like nested ternary expressions, result in a Control Flow Graph (CFG) that doesn't map cleanly to a simple AST structure. For example, consider this C# code:

float s = (cond0 && cond1) ? -1.0f : 1.0f;

The corresponding CFG would look something like this:

b0():
	br_if %cond0, b1(), b3()
b1():
	br_if %cond1, b2(), b3()
b2():
	s = -1.0f
	br b_merge()
b3():
	s = 1.0f
	br b_merge()
b_merge():
    ...

To represent this in a structured way, the b3 block (the else case) would need to be duplicated in the AST, which is not ideal:

if(cond0){
	if(cond1) {
		s = -1.0f;
	} else {
		s = 1.0f; // b3 duplicated
	}
} else {
	s = 1.0f; // b3 duplicated
}

While a select instruction could handle this specific case, it's not a general solution.

Question: Does the Slang IR accept these kinds of CFGs (need to reuse/duplicate block in structural control flow)?

Question 3: Eliminating Unnecessary Pointers

dotnet CIL allows taking the address of arguments and local variables. A direct, 1:1 translation of this logic into Slang source code can produce invalid constructs, particularly for graphics shader targets.

Consider this example:

public static float TernaryConditionalSwizzle(vec3 p, bool cond)
{
    p.xz = cond ? p.zx : p.xz;
    return p.x;
}

My SSA IR for this function might look like this, where pointers to p are passed between blocks:

b0():
	%p_ptr : Ptr<vec3> = address_of(p)
	%c : bool = load(cond)
    br_if %c, b2(%p_ptr), b1(%p_ptr)

b1(%p1_ptr: Ptr<vec3>):
	%val1 : vec2 = get_xz(%p1_ptr)
	br b3(%p1_ptr, %val1)

b2(%p2_ptr: Ptr<vec3>):
	%val2 : vec2 = get_zx(%p2_ptr)
	br b3(%p2_ptr, %val2)

b3(%p3_ptr: Ptr<vec3>, %val: vec2)
	set_xz(%p3_ptr, %val)
	br b4()

b4():
	%p_ptr_final : Ptr<vec3> = address_of(p)
	%result : float = get_x(%p_ptr_final)
	return %result

Those passing of pointer for argument p comes from the dotnet stack IR passing values on stack between blocks.

If I directly emit this IR into Slang source code, it might produce something like following, which is invalid for graphics shader target because it takes the address of a function parameter:

float TernaryConditionalSwizzle(vec3 p, bool cond)
{
	Ptr<vec3> ptr;
	vec2 val;
	if(cond) {
		ptr = &p; // Invalid for shader targets
		val = p.zx;
	} else {
		ptr = &p; // Invalid for shader targets
		val = p.xz;
	}
	(*ptr).xz = val;
	return p.x;
}

In this case, the pointer ptr is actually unnecessary and could be optimized away by a constant propagation pass, as it always points to p, it's just a artifact from stack IR passing value across blocks for reduced instruction count.

Question: Is it feasible to emit Slang IR containing such pointer patterns and rely on subsequent legalization or optimization passes within Slang to eliminate them?

Question 4: Definition of Merge/Join Nodes in Slang IR

I've read in the Design of Slang's IR post that a "join" node in Slang's CFG is not strictly required to be a post-dominator. In my current AST recovery logic, I use the immediate post-dominator of a branch as the merge point for blocks/if-else, and use the first post dominator outside loop region for loops, which works for my limited simple test cases, but I am not sure if it's a valid assumption for all cases.

Question: Although a "join" node is not strictly required to be a post-dominator, if I always use the immediate post-dominator as the merge block when constructing Slang IR, will that always result in a valid IR?

Thank you for your time for reading this, looking forward to your guidance and suggestions.

[tangent-vector]

Thanks for sharing about your project; it sounds interesting!

A lot of the challenges you are running into are very familiar to me, and you'd probably find people with similar experiences who have worked on RustGPU, the clspv project, or dxc. People sometimes ask us why the Slang project didn't build on top of LLVM, or why we didn't start with the clang front-end, and the short answer is that we knew doing so would create all these kinds of challenges, and that there are no truly robust and general-purpose solutions if you want to compile to something like WGSL from a more powerful language like CIL, LLVM IR, or C++ (without adding on tons of restrictions).

Of course, there's a lot that can be done in a system that does a best-effort translation, and I'll try to give responses to your specific questions:

Q1: IR-to-IR Translation?

Short answer: emitting Slang IR from your code generator rather than Slang source code would be more direct, but it is difficult to say with certainty whether it would be a more robust approach.

Potential benefits include:

• You wouldn't need to identify continue vs. break branches (we have code to do that already, in our emit logic)
• Compared to emitting SPIR-V, you could emit higher-level code in many cases (and let Slang legalize it)
• You might be able to translate CIL-level debug information over to Slang IR's constructs for debug information (although those representations can be tricky)

Likely downsides include:

• The Slang IR is intentionally not part of the public API of the Slang compiler, and we don't make any guarantees that it will remain consistent/stable across compiler versions. You'd probably have to make a fork of Slang as part of your work.
• The Slang IR doesn't have a spec, and probably doesn't have enough documentation. It is possible that parts of the Slang compiler back-end rely on unstated invariants around how the Slang front-end structures the IR it generates.
• Much of the functionality of Slang is provided through built-in types and functions and, while some of these map almost one-to-one over to Slang IR instructions, many are encoded in the Slang IR for the core module as ordinary functions (just with lots of decorations), and by default your code would only be able to refer to them by their mangled names (and our name mangling is unstable and unintuitive)

Q2: Control Flow Translation

I believe that the kind of situation you are describing can be handled by inserting loops and using labelled breaks. It is a very contrived way to encode control flow, though.

To render your example in that style:

float s;
L: for(;;) {
    if(cond0) {
        if(cond1) {
            s = -1.0f;
            break L;
        }
    }
    s = 1.0f;
    break L;
}
// ...

I believe that Slang does support labelled break and continue, although the feature doesn't see much use and there might be gaps in the implementation.

I believe that using labelled break like the above allows you to encode basically any reducible CFG into Slang. The only caveat I know of is that the merge points resulting from such code may not be what the original code intended (e.g., in the above example the merge point for the first if is the s = 1.0f line, and not the code after the for loop, as one might want).

Q3: Pointer Elimination

The short answer: Slang does not include the kind of complicated optimizations that would be necessary to fully eliminate pointer use from code written to use pointers.

Related to the comments I made at the start of this post: part of our reason for building the Slang compiler the way we did was specifically to avoid needing to write complicated pointer-elimination and control-flow-restructuring passes. For targets that don't have "full" pointer support, the Slang IR and the Slang language are carefully designed so that we can always compile to those targets without needing to emit code with pointer use.

The desire to robustly support targets without full pointer support is part of the motivation (but not the only motivation) for why the Slang front-end language disallows using & to take the address of most things. We are intentionally not a C/C++ compiler, and the Slang language is intentionally quite different from C/C++.

If you are emitting Slang IR directly, and want to try to implement a pointer-elimination pass in the context of the Slang codebase, that might be one way to approach things. Internal to the Slang IR, things like local variables do have addresses, and function parameters of pointer type can be expressed at the IR level. As you say, many of the transformations you might like to make to eliminate pointers should be reasonably easy to implement (and some might just fall out of the process of emitting Slang IR). The challenge would be making such a pass robust enough to cover all the cases you care about.

The main alternative to doing the pointer-elimination work as a pass in the Slang compiler codebase would be to do it in your own code at the CIL/C# level. Depending on what kind of IR you have built to encode the CIL, you might find it easier to implement the optimizations in your own code than to try and get Slang to do them for you.

Q4: Merge/Join Definition

Short answer: always using the immediate post-dominator as the merge point would lead to Slang IR that is "valid" in the sense that it obeys the invariants that the IR requires. Whether that choice is "valid" or not for the semantics of a particular input program is ultimately up to your programming model and what guarantees you want to provide to users.

There's a ton of subtlety to all of this. If you don't know the relevant details on why ILs and IRs for GPU programming models often care about merge points, you might like to read this blog post that I wrote years and years ago.

For a lot of code merge points can be seen as just an optimization. Merge points start to be semantically significant as soon as you have operations that involve cooperation between threads/invocations: barriers, thread-/work-group-shared memory, warp/wave/subgroup operations, etc. Note that for fragment shaders, even basic things like texture sampling counts as a cooperative operation (because of the implicit computation of partial differences over quad fragments).

As soon as code performs any cooperative operations, the choice of where merge points are placed can (in principle) have semantic consequences, such that places them "too late" or "too early" might result in code computing the wrong values or, much worse, going into an infinite loop or other pathological behavior.

I'm bringing some of this up because it is extremely relevant to you for a project like you are doing, because where your translator ends up placing merge points (via its translation to Slang, SPIR-V, Slang IR, WGSL, or what-have-you) will impact the semantics of the programming model that you expose to anybody using your system. Unfortunately, that means that the decisions made in the front-end compiler (for C# or whatever) that generates CIL, as well as your control-flow-restructuring pass will also have an impact on what a user's programs mean.

The concrete example I always use (which is shown in the blog post I linked), is code that tries to implement something like mutual exclusion via atomics. Consider pseudo-code like the following:

before();
for(;;)
{
    if(grabMutex())
    {
        doSingleThreadStuff();
        releaseMutex();
        break;
    }
}
after();

The intention of pseduo-code like that is clear:

• all the active threads in a subgroup/wave/warp enter the loop and compete to try to grab the mutex
• whenever a thread succeeds in grabbing the mutex, it does some critical work, releases the mutex, and then exits the loop
• once all the threads have exited the loop, they "merge" and resume at after(), with all the same threads active that were active at before()

The problem is that the after() part of the code above is not the immediate post-dominator of the for loop, nor of the if inside the loop. If you work out a CFG for this code, you'll probably find that it is the same CFG you get for:

before();
for(;;)
{
    if(grabMutex())
    {
        break;
    }
}
doSingleThreadStuff();
releaseMutex();
after();

The user-perceived semantics of this latter chunk of code is quite different from what they assumed the earlier example meant:

• all the active threads in a subgroup/wave/warp enter the loop and compete to try to grab the mutex
• one thread grabs the mutex, and then immediately jumps out of the loop (where it presumably starts waiting on the other threads to join it)
• the rest of the threads in the subgroup/wave/warp can never exit the loop, because they will never succeed at grabbing the mutex while the first one has it
• the shader never terminates and your GPU driver might force a TDR

(Note that I'm not saying either of these semantic interpretations is definitely going to happen for that kind of input code across all languages, APIs, and hardware...)

To a programmer's intuition, there is something semantically different between the two cases, because in one case the releaseMutex() call is "inside" the loop, and in the other it is "after" the loop. But if all you consider is immediate post-dominators, then you can't distinguish those two cases (and many others).

The ecosystem that Slang, GLSL, SPIR-V, and WGSL sit in recognizes that the distinction there matters. High-level languages like Slang and GLSL define their semantics in terms of the shape and nesting structure of the AST (see how GLSL defines "uniform control flow"), and an intermediate language like SPIR-V provides a way to encode those semantics as part of a CFG (via merge points). The dxc compiler for HLSL has had modifications made in the past to introduce fake bool variables for control flow, to force the LLVM CFG that the front-end produces to encode enough extra information for the back-end to implement the intuitively-correct semantics in cases where it was defying programmer expectations.

You are ultimately the one who gets to decide what the semantics of your programming model will be.

My strongly held opinion (based on my own experience in this domain) is that the a compilation stack should either provide reconvergence/join/merge behavior based on the shape of the input AST in the source language (which tends to match what programmers expect/want the behavior to be), or they should provide maximal reconvergence (which I guess you can request via VK_KHR_shader_maximal_reconvergence for Vulkan). If all you have is an unstructured CFG, then maximal reconvergence may be the only option you can easily implement (and it should be something you can modify your control-flow restructuring pass to provide).

I haven't worked on the theory of this stuff for a while, but I seem to recall that for structured input code, the "programmer intuition" model and maximal reconvergence are the same, so it is probably okay to treat maximal reconvergence as the correct generalization to arbitrary CFGs. Just note that neither of the two "good" definitions of reconvergence/merge behavior is defined in terms of immediate post-dominators.

[tangent-vector]

Random: looking at the abstract for the paper you linked, I'm very pleased to see it reference the 1973 work from Peterson, Kasami, and Tokura. It is unfortunate that so many people only credit Relooper as the origination of the idea of restructuring an arbitrary CFG, when a working algorithm had been published many decades prior.

[Hong-Xiang]

Hi @tangent-vector , Thank you so much for your clear and detailed response—it's been incredibly helpful and has sparked several new ideas that I'm excited to explore. These approaches may help address some of the challenges I mentioned earlier.

Q2: Control Flow Translation

Your explanation on using labelled break to encode control flow code generation really opened my eyes to new possibilities. I previously thought labeled breaks were primarily a convenience feature for exiting nested loops, but your example demonstrates they're much more powerful than that. The pattern you showed bears a striking resemblance to WebAssembly's break-to-outer-scopes mechanism, which aligns well with my current IR design.

I'm now investigating whether labeled breaks can be used to emulate WASM-style br/br_if instructions that target arbitrary nested scopes. For example, it seems I can use this pattern to eliminate the need for explicit scope checking when deciding between continue or break:

for(;;){
    ... // b1
    if(c) {
        continue;
    }
    ... // b2
    if(c) {
        break;
    }
    ... // b3
}

This could be encoded using only break statements as:

L1: for(;;){
    L2: for(;;) { // a dummy loop for encoding continue
        ... // b1
        if(c) {
            break L2; // encoding continue using break
        }      
        ... // b2
        if(c) {
            break L1;
        }
        ... //b3
        break; // dummy loop L2 is logically a block, thus a unconditional break is needed
    }
}

This raises two questions I'd appreciate your thoughts on:

1. Based on the documentation and my preliminary testing, it appears that Slang currently supports labeled break but not labeled continue. Is that correct?

2. Are there any potential pitfalls to encoding control flow fully using this pattern for all blocks/regions? Although this might not be a pattern commonly written by developers manually, I'm hoping it will be properly normalized into standard Slang IR during parsing.

Q3: Pointer Handling and Legalization

Thank you for highlighting that the key challenge is determining whether optimization passes alone are sufficient for legalization in all cases. It definitely sounds unlikely, so your insight has prompted me to consider a more robust alternative approach.

Since my requirements are limited to supporting the logical memory model with pointers only from parameters and local variables (a compile-time fixed set), I'm exploring an enum-based encoding scheme. The idea would be:

• For each function exhibiting Ptr<Ptr<t>> to local variable/function parameters patterns and each pointer type involved, use an integer as a runtime encoding for those pointers
• Implement load/store operations via helper functions with in out parameters and switch statements

thus for a function

int foo(int v1, int v2, bool c) {
   Ptr<int> p;
   if(c) {
     p = &v1;
   }else{
     p = &v2;
   }
   *p = 42;
   return *p;
}

it seems it could be encoded as

int foo(int v1, int v2, bool c) {
   int ptag;
   if(c) {
      ptag = 0; // address of becomes enum/tag assignment
   } else {
      ptag = 1;
   }

   // load/store to ptr become calling helper function
   foo_int_ptr_store_helper(ptag, 42, v1, v2); 
   return foo_int_ptr_load_helper(ptag, v1, v2); 
}
void foo_int_ptr_store_helper(int tag, int value, in out int v1, in out int v2) {
    switch(tag){
       case 1:
          v2 = value;
          break;
       default:
          v1 = value;
          break;
    }
}
int foo_int_ptr_load_helper(int tag, in out int v1, in out int v2) {
    switch(tag){
       case 1:
          return v2;
       default:
          return v1;
    }
}

This is conceptually similar to how interface-based runtime polymorphism can be compiled down into tagged unions. I'm planning to prototype this to see if it actually works.

---

If both of these explorations above yield positive results, it seems current most challenging aspects of source code emission could be resolved. This might make it worthwhile to invest more time in the source-to-source compilation approach before pivoting to IR emission.

---

Q4: Merge Points and Control Flow Recovery

The concept of different semantics of merge points for GPU programs was new to me—thank you for the thorough explanation and references! Your example helped me realize I may have already encountered a related phenomenon.

In some cases where source code has a loop followed by a return statement, my current control flow recovery implementation produces a structure that initially surprised me: it places the post-loop block inside the loop body itself.

Original source pattern:

for(;;) {
  ... // block a
  if(cond) {
    break;
  }
  ... // block b
}
return v;

Recovered structure:

for(;;) {
  ... // block a
  if(cond) {
    return v;
  } else {
    continue;
  }
  ... // block b
}

While this looks unusual, it's semantically equivalent from a standard CPU program perspective. What's particularly interesting is that some emissions of this pattern pass the Tint WGSL compiler but fail in Naga, with Naga complaining about the missing return statement in the function.

After reading your explanation, I realize this is somewhat the inverse of your example. I initially thought this might be a compiler bug, but your insights suggest there's something deeper here worth understanding. I'm going to diving deeper into this area!

---

Thank you again for taking the time to provide such thoughtful and educational responses. Your help is greatly appreciated!

[tangent-vector]

I'm glad that you found my reply helpful. I certainly enjoy talking about this kind of stuff.

Q2: Control Flow Translation

2.1: Multi-Level continue?

I had somehow assumed that we added multi-level continue support to Slang at the same time as multi-level break, but I just now looked inside the implementation and confirmed that only the break statement supports using a target label.

You are correct that the effect of a multi-level continue can be emulated using only breaks by nesting loops. In theory an IR for structured code could get away with only supporting a very small number of control-flow constructs: you just need at least one conditional branch (if or switch), a way to loop, and a way to break out of (one or more) loops.

2.2: Possible pitfalls?

I think it is realistic to expect that encoding control flow in the way we are discussing, using multi-level break could affect the quality/performance of the resulting code.

The way that Slang handles multi-level break on targets that can't support it is by introducing additional bool variables and conditional control flow to emulate the desired behavior. It's not that we have no optimization around this stuff but, as you say, this isn't a common idiom in user code so we may not have all the passes that would be ideal for cleaning up the code that results from such a translation.

As an example, I do not believe the Slang codebase currently has a pass that could take your example of using nested for(;;) loops to overcome the lack of multi-level continue, and then optimize that back into a single loop that makes use of both the break and continue paths for SPIR-V/WGSL/etc.

There are things that could probably be improved on the Slang implementation side, to make this go more smoothly, so if you end up pursuing this plan and get interested in contributing to the Slang codebase, we would definitely consider PRs that implement these kinds of control-flow optimizations.

Q3: Pointer Handling and Legalization

The approach you are describing should in theory be implementable (provided the input code matches the constraints you need), although it might end up being logistically heavy-weight.

The important thing that makes the translation you describe tractable is that you can exhaustively enumerate all of the possible targets that a single pointer might point to/into (basically, everything that the pointer might alias). If you had to deal with input code that, for example, read a pointer our of a global variable (or a heap-allocated object, etc.) and then tried to load/store from that pointer, you'd have no easy bound on what such a pointer might alias.

The biggest challenge I see for the exact kind of transformation you describe is that your *_helper functions could grow unwieldy and slow if there are a large number of variables/locations that a pointer could potentially point to/into. There are ways you could imagine trying to mitigate that:

• You could try to do an analysis path that computes, for each pointer-type variable, a smaller set of variables/locations that it can ever point to, and make sure that the conditionals you generate for load/store of that pointer-type variable only worry about the possibility of those specific variables.

• You could instead go the other way, and collect all variables of a single type that are ever pointed to into a single array, and then replace pointers to those variables with indices into the array. At that point the load and store operations just read or write elements of the array.

• You should almost certainly be looking into whether you can do some kind of analysis pass, such as transforming your input code to SSA form and promoting "stack-allocated" variables to SSA register where possible, since such passes could likely eliminate a lot of pointer use in the code.

I don't have a great handle on what approach would yield the best overall performance. Both the switch based emulation and the idea of using a flat array to hold all the locals are worrying because I'm not confident that downstream compilation in Slang (and below) can easily optimize those idioms to recover clean idiomatic code.

Q4: Merge Points and Control Flow Recovery

Yes, the situation you ran into there is indeed a comparable case to what I was writing about. If there was code right before the return in your example that did some kind of cooperative operation within a wave/warp/subgroup, then pulling that code up into the loop body could mean the operation is now under non-uniform control flow whereas if was previously under uniform control flow when placed after the loop, and thus the behavior (and correctness) of the code could potentially change.

Another interesting property of transformations like that is that they can end up changing the apparent lifetime and scoping behavior of a program. Even with the structured control-flow information we have in Slang, it is possible for ordinary optimization passes to do things like transform the code "after" a loop so that it refers to a variable that was originally declared inside the loop body (because the SSA rules for def-before-use only care about the dominator tree computed from the CFG). Then when the time comes to emit high-level-language source code back out of our IR we need to detect such cases and fix up the code so that what we emit doesn't do invalid things around scoping.

For what it's worth, I believe it is possible for somebody to write a control-flow restructuring algorithm that also incorporates the definition of "maximal reconvergence" (as implemented by the Khronos-defined extension matching that name), and thus recover a structured AST such that the merge points implied by the AST structure (which a compiler like Slang will use) implement maximal reconvergence for the input CFG. I haven't implemented such a pass myself, though, so I don't know how challenging it would be in practice.