Post · bonfire.cafe

Post

I fixed x86 tail calls in LLVM

https://github.com/llvm/llvm-project/pull/168956

Tail calls passing structs had been broken since forever, and it made me mad enough to write C++.

It's a little tricky because sometimes it requires shuffling values around on the stack and you have to make sure to not overwrite values you'll need later. This was fixed in the arm backend a while ago, and I was able to port that approach to the x86 backend. The plan is to include this in LLVM 22.

Together with some other changes it seems like guaranteed tail calls in rust might actually, finally happen.

#llvm #rustlang

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange replied · 3 weeks ago

@folkertdev

The guaranteed tail call stuff in Clang has some unfortunate issues with the always-online attribute, where you can write code both the can do tail-call elimination in the back end that the front end will reject and vice versa.

If people are working on this in Rust, I’m curious whether they have a solution to this. Does Rust for forced inlining in the MIR layer? That should make it easier to fix than for Clang.

Folkert de Vries

@folkertdev@hachyderm.io replied · 3 weeks ago

@david_chisnall one additional change in that PR is that when a call is marked as musttail, but this is not actually possible to codegen, the backend will error instead of miscompile.

The rust `inline(always)` is explicitly a hint, that may be ignored. A guaranteed tail call (using the `become` keyword) must lower to a direct jump.

Finally rust can technically do forced mir inlining with the internal `#[rustc_force_inline]` attribute, but that is not currently exposed on stable.

Because tail calls have been experimental, I don't think we have a lot of data yet on this sort of inlining issue. Is there some small example that shows the issue you're describing?

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange replied · 3 weeks ago

@folkertdev

We have an issue in clang, which I can try to find. It came up in snmalloc, where we took a common sequence from some functions and outlined it in the source with an always-inline attribute to put it back. This function contained a call to a function that was marked as must-tail. The front end looked at the signature of the (to-be-inlined) call and the callee and reported that tail calling was impossible. After inlining, it was possible at all call sites, but the front end didn’t do analysis across the scope of the caller.

Ideally, the front end would error if you called the always-inline function at any point where the must-tail call cannot be tail called.

0xPsi

@oxpsi@mstdn.plus replied · 3 weeks ago

so is the idea that the must-tail contract should be checked on the outlined fn's signature as if it were a strange little trampoline creature, rather than only at the original site? or am i petting the compiler cat backwards here?

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.2-alpha.7 no JS en

Automatic federation enabled