Implementing Closures in MIR C Efficiently

[darko20]

I'm trying to implement closures using MIR C and I'm wondering about the efficiency of the following code:

typedef struct cl {
  int a, b, c;
} *cl;

int c(const cl l, int d, int e) {
  l->a = d;
  return l->a + l->b + l->c + e;
}

Will the optimiser always generate code similar to local variable access for a, b and c? If not Is there anything that can be done to improve efficiency?

[vnmakarov]

I don't know what do you mean exactly. I see not necessary read memory l->a right after its storing. It is not that bad as modern processors have store-to-load forwarding but still it is better to remove redundant load.

MIR-generator right now does practically nothing for memory access optimizations.

I am sure I'll work on improving code for memory accesses. I thought about this many times. On the first stage it will be probably adding alias info to MIR memory operands, generation of this info by c2m based on type info, and using alias info for moderate memory optimizations. In the future flow sensitive point-to-analysis might be implemented.

I'd like to keep a balance between optimization complexity and its performance impact. The complexity of GCC/LLVM is so big and results in permanent struggling with optimization bugs. I know it well as half of my work time I spend on fixing RA PRs in GCC.

[darko20]

I guess I should have asked if the code will be compiled such that const argument l and its members will work like a frame pointer does with local variables.

I think simplicity and predictability (and less bugs) is definitely the right approach with optimizations. I'm mostly concerned with the trade offs with different approaches to my generating C code.

I think I should probably study MIR instruction code output to get a better idea of what happens in different scenarios.

[vnmakarov]

I guess I should have asked if the code will be compiled such that const argument l and its members will work like a frame pointer does with local variables.

Yes, the code for accessing fields is already generated analogously to accessing to local variables on the stack through frame pointer.
l is most probably getting a hard reg hr and fields accessed by <field offset>(hr) as for local variable on the stack <stack offset>(frame pointer reg).

And you don't need to use const for l definition to get such access code.

Still using const might help for the future optimizations to remove redundant loads/stores. Currently for int c(const cl l, int d) {l->a=d;return l->a MIR generator produces code like

mov %rsi,%(rdi) # l->a = d;
mov (%rdi),%rax; ret # return l->a

But it could produce with the right optimizations (GVN) using alias analysis:

mov %rsi,%(rdi) # l->a = d;
mov %rsi,%rax; ret # return l->a

[darko20]

Thanks, that's very helpful. I should be able eliminate redundant load/stores and will do other optimizations since all of my C code is generated.