Background: Mixed value/memory semantics in EmitC The EmitC dialect currently identifies MLIR SSA values with C variables: The translator is assumed to generate a C variable for each SSA value, and the dialect supports taking that C variable’s address via its emitc.apply op. Consider the followin…

Hi Gil, Thank you for the detailed RFC. I thought about a variation of your second suggestion, that may work without having to work with symbols all the time. We could make lvalues part of the type system by introducing an !emitc.lvalue type. The emitc.automatic operation or a repurposed emitc.vari…

Hi Simon, Sorry for the late response. Sounds good to me! Explicitly modeling the l-value-to-r-value memory access would allow most ops to remain side-effect free. I guess the derefence op (either apply or a new one) would also be generating l-values, right? We may need to work a bit harder when ve…

[image] aniragil: Modelling function, call and return ops is something I’ve been wanting to do anyway in order to handle multiple return values at the dialect level rather than in the emitter, so that can perhaps be done separately in advance. I’ve added those on Feb. 4th, see [mlir][EmitC] A…

Good to hear! Would be happy to collaborate on it upstream.

Here is the current state of the prototype to discuss on one of the alternatives proposed above: EmitC lvalue . (I haven’t put to much thought into the changes in the emitter or validation of the ops. I just added code where ever needed to make most of the tests pass.) To summarize the changes. Ops …

Thanks for pushing through with this Simon! During emission these ops don’t produce any output. Instead the mapping from SSA values to variable names explicitly checks if the defining op is an LValueToRValueOp and then recursively looks up the variable name of it’s operand Not sure I follow: Won…

Hi all, I started working on the LValue type again. I got all upstream tests passing except for one that uses nested for ops. I think this has to do with how I update users of the iter_args values. I will continue with this next week and will keep you updated.

I’ve created [WIP][mlir][EmitC] Model lvalues as a type in EmitC by simon-camp · Pull Request #91475 · llvm/llvm-project · GitHub as a starting point for discussions.

[RFC] Separate variables from SSA values in EmitC

MLIR

simon-camp March 4, 2024, 3:35pm 5

I’ve started to prototype this in a downstream project. I’m currently hitting a few errors where some lvalue-to-rvalue conversion ops are missing.

Topic		Replies	Views
PSA: Modelling memory of EmitC variables Deprecation & Important Refactoring	0	131	August 5, 2024
Simple C++ emitter rev MLIR	21	3346	May 28, 2020
[PSA][EmitC] Replacing the `emitc.apply` operation Deprecation & Important Refactoring mlir	0	91	December 5, 2025
Playing around with a C dialect and wondering about how high-level it should be MLIR	4	1584	February 16, 2023
RFC: Global Variables in MLIR MLIR	18	2759	October 26, 2020

[RFC] Separate variables from SSA values in EmitC

Related topics